Bug 49118 - With cairo 1.12, libreoffice impress slide show does not output anything on screen when in slideshow mode
Summary: With cairo 1.12, libreoffice impress slide show does not output anything on s...
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: image backend (show other bugs)
Version: 1.12.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-24 14:14 UTC by Eric Valette
Modified: 2012-06-03 09:52 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Attachments
filtered xtrace with cairo 1.10 showing working state (68.55 KB, text/plain)
2012-04-25 02:24 UTC, Pauli 		Details
filtered xtrace with cairo 1.12 showing broken state (66.32 KB, text/plain)
2012-04-25 02:25 UTC, Pauli 		Details
Bactrace when extra pixmap is created and copy to the pixmap (9.50 KB, text/plain)
2012-04-25 09:42 UTC, Pauli 		Details
First difference is surface creation with width and height zeros (10.09 KB, text/plain)
2012-04-25 12:26 UTC, Pauli 		Details
View All

Description Eric Valette 2012-04-24 14:14:10 UTC 
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.

see https://bugs.freedesktop.org/show_bug.cgi?id=47266

and debian bug 668172
Comment 1 Chris Wilson 2012-04-24 14:46:43 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.
Comment 2 Eric Valette 2012-04-24 14:57:03 UTC 
(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!.
Comment 3 Pauli 2012-04-25 02:24:47 UTC 
Created attachment 60561 [details]
filtered xtrace with cairo 1.10 showing working state
Comment 4 Pauli 2012-04-25 02:25:26 UTC 
Created attachment 60562 [details]
filtered xtrace with cairo 1.12 showing broken state
Comment 5 Pauli 2012-04-25 02:27:53 UTC 
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.
Comment 6 Pauli 2012-04-25 09:42:20 UTC 
Created attachment 60585 [details]
Bactrace when extra pixmap is created and copy to the pixmap
Comment 7 Pauli 2012-04-25 12:26:49 UTC 
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.
Comment 8 Chris Wilson 2012-04-25 12:38:30 UTC 
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.
Comment 9 Chris Wilson 2012-04-25 12:56:13 UTC 
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>
Comment 10 Eric Valette 2012-04-25 12:59:35 UTC 
Thanks to all people who contributed to fix it.
Comment 11 Paul Menzel 2012-04-26 00:07:15 UTC 
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?
Comment 12 Eric Valette 2012-04-26 00:10:13 UTC 
(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.
Comment 13 Eric Valette 2012-04-26 01:18:26 UTC 
> Will do. Will mention the minimal 1x1 instead of 0x0.

Done see : https://bugs.freedesktop.org/show_bug.cgi?id=49165
Comment 14 madbiologist 2012-06-03 09:52:07 UTC 
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.