Issue 100888 - Provide optimized VCL copy from VDEV to VDEV with mask (also VDEV)
Summary: Provide optimized VCL copy from VDEV to VDEV with mask (also VDEV)
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: DEV300m45
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-04-06 14:22 UTC by Armin Le Grand
Modified: 2017-05-20 11:35 UTC (History)
2 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

experimental patch v1 (16.10 KB, patch)
2010-07-19 14:52 UTC,
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2009-04-06 14:22:00 UTC
AW: For primitives, masking is done opening a VDEV (A) for the target region and
painting the child primitives to it. A 2nd VDEV (B) for the mask is created and
the mask primitive(s) are painted to it. From both Bitmaps are fetched and
merged to a BitmapEx. That bitmap is painted to the real destination. All this
happens without MapMode in discrete coordinates (pixels).
For complex transparences, the same happens with exchanging (B) with a 8bit
alpha mask.
Both operations would profit heavily by offering something like

void DrawOutDevMasked(
    const Point& rDestPt, const Size& rDestSize,
    const Point& rSrcPt,  const Size& rSrcSize,
    const OutputDevice& rOutDev ,
    const OutputDevice& rMaskOutDev);

where rMaskOutDev has to be 1bit or 8bit depth and is defined as transparence mask.
Comment 1 Armin Le Grand 2009-04-06 14:26:26 UTC
AW: Setting to enhancement, of course.
Comment 2 2009-04-06 14:29:48 UTC
accepted, but a 3.2 target is too optimistic
Comment 3 2009-09-10 08:08:18 UTC
advancing target
Comment 4 2010-07-19 14:35:40 UTC
Experimenting with the enhancement on UNX/WIN/OSX shows that the benefit is not worth it for the 
urgent target:
- on UNX the cost is still very much dominated by the polygon drawing => Amdahls law
- on WIN/OSX there is no API that allows the blending of e.g. off-screen layers on the graphics card in 
the way needed for the requested functionality (i.e. the mask is first drawn on a grayscale device, then 
reinterpreted as alpha mask to be merged with a source layer onto a target layer). Having the grayscale 
image as a transparency mask as opposed to the much more common alpha mask doesn't help either.  
The canonical fallback is to get the bitmaps of both input layers, merge them to an alpha-image and 
draw them again which exactly what is already done by the getBitmap+drawBitmapEx methods, so 
there wouldn't be any significant speedup.

I'll attach the current experimental patch as baseline for further work. At least the requested method 
could be added to the output device so that middle layers could use this interface instead of 
implementing the canonical fallback by hand.
Comment 5 2010-07-19 14:52:05 UTC
Created attachment 70688 [details]
experimental patch v1
Comment 6 Marcus 2017-05-20 11:35:11 UTC
Reset assigne to the default "".