I upgraded my system and tried to view a impress presentation to see what it gives full screen. The behavior was rather strange:: the visual output stay onchnaged but nothing was clickable anymore. On a short presentation I realized that I did not see the slide but when clicking the mouse the number of slide I did see the regular exit message. So the sslideshow mode was activated but the slide not displayed.
Searcifo ug in debian I found it but affected to cairo with an upstream bug targetting EXA acceleration. But, other pointed that the bug was happening with Intel driver as weel and I use nvidia. Disabling hardware acceleration for impress did fix the problem. However, it was working before (at least I did not chnage my libreoffice settings.
and debian bug 668172
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.
Author: Chris Wilson <email@example.com>
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 <firstname.lastname@example.org>
Signed-off-by: Chris Wilson <email@example.com>
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.