On Thu, Nov 19, 2015 at 11:02:32AM +0000, Caolán McNamara <caolanm@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 474228f89128487ea7a216580df0a8bc5e06f87e. 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.
Attachment:
signature.asc
Description: Digital signature