| Summary: | With cairo 1.12, libreoffice impress slide show does not output anything on screen when in slideshow mode | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Eric Valette <eric.valette> |
| Component: | image backend | Assignee: | Carl Worth <cworth> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | b3nton, eric.valette, paulepanter, siarhei.siamashka |
| Version: | 1.12.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
filtered xtrace with cairo 1.10 showing working state
filtered xtrace with cairo 1.12 showing broken state Bactrace when extra pixmap is created and copy to the pixmap First difference is surface creation with width and height zeros |
||
|
Description
Eric Valette
2012-04-24 14:14:10 UTC
As far as I can tell so far, Cairo is doing exactly as asked. I can see Cairo rendering, and the output looks correct, I just can't see how loimpress fails to copy it to its presentation window. (In reply to comment #1) > As far as I can tell so far, Cairo is doing exactly as asked. I can see Cairo > rendering, and the output looks correct, I just can't see how loimpress fails > to copy it to its presentation window. Dunno eiher but as you can see by browsing the bug in debian: 1) a lot of people are affected, 2) either disabling rendering accel in libreoffice settings or reverting to previous cairo lib fixes the problem in impress, so at least there is a misbehavior when the two are there!. Created attachment 60561 [details]
filtered xtrace with cairo 1.10 showing working state
Created attachment 60562 [details]
filtered xtrace with cairo 1.12 showing broken state
Differences what I can see: * Copies from cairo render target and backing pixmap were done with render composite in 1.10. But 1.12 changes those copies to XcopyArea. * 1.12 create a 2nd backing pixmap that looks like it should be the window instead. That means the last copy to onscreen memory actually goes to X pixmap that is never show in screen. Created attachment 60585 [details]
Bactrace when extra pixmap is created and copy to the pixmap
Created attachment 60587 [details]
First difference is surface creation with width and height zeros
Cairo 1.10 used to create xlib surfaces even if width and height where zeros. But 1.12 returns surfaces with all fields zeros and refcount -1.
That is the root cause of the issue. lo creates a 0x0 surface to point to its primary display it seems. We mark that as invalid and so all drawing to that surface (in this case, the screen) is discarded. commit 9e81c5b737cda9dc539b2cf497c20ac48ddb91ac Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 25 20:41:16 2012 +0100 xlib: Allow applications to create 0x0 surfaces Although 0x0 is not a legimate surface size, we do allow applications the flexibility to reset the size before drawing. As we previously never checked the size against minimum legal constraints, applications expect to be able to create seemingly illegal surfaces, and so we must continue to provide backwards compatibility. Many thanks to Pauli Nieminen for trawling through the protocol traces, diving into the depths of libreoffice and identifying the regression. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49118 (presentation mode in loimpress is blank). Reported-by: Eric Valette <eric.valette@free.fr> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks to all people who contributed to fix it. An entry to a news file should be added, that this is just a work around and that programs should be updated to adhere to the spec. Eric, could you submit a report to LibreOffice’s upstream bug tracking system mentioning that issue? (In reply to comment #11) > An entry to a news file should be added, that this is just a work around and > that programs should be updated to adhere to the spec. > > Eric, could you submit a report to LibreOffice’s upstream bug tracking system > mentioning that issue? Will do. Will mention the minimal 1x1 instead of 0x0. > Will do. Will mention the minimal 1x1 instead of 0x0. Done see : https://bugs.freedesktop.org/show_bug.cgi?id=49165 This work-around is included in cairo 1.12.2. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.