Open attachment 119549 [details] in gtktiledviewer with yellow background: bin/run gtktiledviewer $PWD/instdir/program /path/to/test.odp --background-color yellow Not only the area outside slides, but also the white slide background is also yellow, as the tiles are transparent there. Bibisect says the range is 8c10722513b24b47b91f6469684f59c5136f574d..e5b3ec9683e4c5761633a1a3c4819a039e796b01, that's when the cairo changes went in affecting tiled rendering. I'll try to bisect it down to a single commit.
876a67f22f123190f9970832f68625ca6825f088 is good 0721765417f787c8f4b1382b5d9100fa3a2a61ad is bad 3dc8907dd32281192c47030d16c5628eccc23564 is bad e34f290eec4f3c8d42724f1602029f5680aecde6 is good c43a3a58677b467274ce6c21d7db1a6c0cc65cb4 is good (as in at least the white slide background is not transparent, but transparency outside the slide area is already broken) b639fe60eab2a221e23dc9d509f9281857d656a3 is bad b639fe60eab2a221e23dc9d509f9281857d656a3 is the first bad commit commit b639fe60eab2a221e23dc9d509f9281857d656a3 Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Nov 19 11:51:47 2015 +0000 VirtualDevices either match another device depth, or are 1 bit cairo can therefore always render to a svp virtual device with need for a fallback Change-Id: I5d03ae541820389e26f7448444444be009fb28a4 :040000 040000 156addd89f6eee6cd6bbf2a9997f1611ee3d6619 e3966f5c48bd50ffa472cc56c5b27304b6eef073 M canvas :040000 040000 b5ed8f36d37b7b2f1a887a197db879bf72e1dab0 92191cea21f778b39b5cc47d90ac1da6d48d68aa M chart2 :040000 040000 b307a9ca27d9d8fb3afe84cc792119645409911e 0a7c200c4a0db904b565483074a9805eaa957ce1 M cppcanvas :040000 040000 0c84db4a13ba9b56b82cfca25cf112d162b74337 5703f373be33d30702dc0f83bf438998805e72b6 M desktop :040000 040000 f43e18010c2affb6abb4a41b2070474cab5d83c6 fbe017ee09b574e9c7cf6fbdc977dce1c36b47a9 M drawinglayer :040000 040000 bc234efbe1a2118d802e0ba34f431be2d6ce39a5 7b2e4c167eebe1f700f79996afc599e65dc5f91d M include :040000 040000 376e9df5b3891320f4677321f7e524749055bf5e 9c2d93c4369aca892fe78bb1010e9c08ac28ffd2 M sd :040000 040000 a7968eb8fa87984f8aa6b9f3639a1fdb3a4be21e 09223c23d45974df856cf17a64f8228a720630c8 M svtools :040000 040000 9057d7fb6c94514d2f5aa44ca01563fc0f4cebe3 724ae813d429265b035936214446780fc8fb3268 M svx :040000 040000 c6834837751966aa94143c1a5d79e1303a3b9bf7 3c1c8a23c0615abb873ec5bee715f0ff25f1d5a1 M sw :040000 040000 143c30673b2aae66803d819d92ec81ca70194aee 13bf50fa9fbc61853ff06ca1778d41eb95a92fae M vcl Adding Cc: to caolanm@redhat.com; Could you possibly take a look at this? Thanks
The good news is that changing SvpSalGraphics::drawPolyPolygon to return false makes this work, i.e. the regression is because that now gets used because its now a cairo compatible surface, so the bug is apparently in the implementation of that drawPolyPolygon
The "fancy pants" drawing api versions don't expect there to be a dedicated separate alpha device apparently. They expect that's only in use for faking true alpha on other code paths. So, https://gerrit.libreoffice.org/#/c/20440/ seems to work fine for me. Simplifies things too.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc45215ec6e5d508415465ad3f619c3dbe23f7c8 Resolves: tdf#96224 don't fiddle around with a separate alpha buffer It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b7776fac09797c910de6bce615409eeecdeb65c&h=libreoffice-5-1 Resolves: tdf#96224 don't fiddle around with a separate alpha buffer It will be available in 5.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.