virtual device depths
vmiklos at collabora.co.uk
Thu Nov 19 05:40:52 PST 2015
On Thu, Nov 19, 2015 at 11:02:32AM +0000, Caolán McNamara <caolanm at redhat.com> wrote:
> There is one other use of an explicit 8 bit virtual device in
> desktop/source/lib/init.cxx for the libreofficekit stuff. But only on
> the non-android code path. In what circumstances does the transparency
> get set to something other than non-solid in that paintTile ? I'd sort
> of imagine that the document background color is always going to be
> solidly filled into the tile ?
The border around sw pages is a semi-transparent shadow. In the desktop
case we have this grayish document background, and we simply paint the
semi-transparent shadow on top of that. In case of tiled rendering the
background is transparent, and we still want to have the
semi-transparent shadow, so the client application that invokes
paintTile() can decide what is the background color.
That's why we need more than 1 bit transparency in the paintTile() case.
Given that VCL really wants a separate device for alpha, we create two
devices, pass them to VCL, and after painting finished, we merge the two
together to mimic RGBA output, as seen by clients.
sw uses transparent instead of gray for doc background since
4fe010cce872ef035fec376298e416f9799c4a21, sd does the same since
If some change needs testing to see if it breaks this transparency
scenario, I think the easiest is to set the background in gtktiledviewer
to some non-gray color, then it's easy to see what breaks if we would go
back to 1-bit transparency.
Hope that answers your question. :-)
The reason transparency is disabled on Android is probably either
performance or because the client code is not capable of handling
transparent PNGs, Tomaz knows the details.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the LibreOffice