Bug 49165 - OpenOffice fails to display anything on screen when using cairo 1.12 (1.10 works) and enabling hardware acceleration in settings
Summary: OpenOffice fails to display anything on screen when using cairo 1.12 (1.10 wo...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
3.5.3 release
Hardware: All Linux (All)
: medium major
Assignee: Not Assigned
Depends on:
Reported: 2012-04-26 01:16 UTC by Eric Valette
Modified: 2017-07-13 08:02 UTC (History)
6 users (show)

See Also:
  • 49118
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Eric Valette 2012-04-26 01:16:41 UTC
The bug has been initially filled to cairo 

But after careful analysis, it happens that libreoffice creates surface of 0x0 size which is forbidden in the specs (Xlib requires at least 1x1) and correct the size before displaying it.

Unfortunately, a change in cairo to be complaint with the specs breaks libreoffice slideshow. There are now a good dozen of bugs in debian and until cairo 12.1 is available, it could be wyse to fix in in 3.5.3.

In the link above you have a full backtrace that exhibits the call path for the 0x0 size
Comment 1 Paul Menzel 2012-04-26 01:40:52 UTC
The corresponding commit [1] allowing such “illegal” behavior is already committed the Cairo repository.

[1] http://cgit.freedesktop.org/cairo/commit/?id=9e81c5b737cda9dc539b2cf497c20ac48ddb91ac
Comment 2 Eric Valette 2012-04-26 02:18:04 UTC
(In reply to comment #1)
> The corresponding commit [1] allowing such “illegal” behavior is already
> committed the Cairo repository.

However, cairo maintainer indicated that while he agrees that the cairo behavior did change, he thinks that creating 0x0 surface still should not be allowing as it not allowed in X protocol. He is the comment in the patch

/* Note: the minimum surface size allowed in the X protocol is 1x1.
 * However, as we historically did not check the minimum size we
 * allowed applications to lie and set the correct size later (one hopes).
 * To preserve compatability we must allow applications to use
 * 0x0 surfaces.
Comment 3 Fabio Coatti 2013-11-02 18:13:44 UTC
Not sure if the reason is the same, but the behaviour is the same with cairo 1.12.16 and libreoffice
Maybe some regression?
see here, not sure if it is a duplicate or not because I don't know if the root cause is the same: https://bugs.freedesktop.org/show_bug.cgi?id=70987
Comment 4 QA Administrators 2015-04-19 03:20:33 UTC Comment hidden (obsolete)
Comment 5 Eric Valette 2015-04-19 17:10:16 UTC
If you have not fixed it the bug is still there. I cannot test as cairo has been changed for compatibility reason and because you haven't responded in a timmely manner.
Comment 6 Fabio Coatti 2015-04-19 17:31:46 UTC
This bug is confirmed to be present also in LO

cairo: 1.14.2

the behaviour is exactly the same as described earlier.
Comment 7 Fabio Coatti 2015-07-20 07:27:08 UTC
Still here, libreoffice & cairo 1.14.2
Comment 8 Fabio Coatti 2015-07-31 16:28:19 UTC
Some info: on gentoo, compiling cairo (1.14.2) without xcb renderer over xlib seems to fix this behaviour.
Comment 9 QA Administrators 2016-09-20 10:21:10 UTC Comment hidden (obsolete)
Comment 10 Paul Menzel 2017-07-13 07:37:12 UTC
Xisco, why did you touch this bug after such a long time, and even changed the “resolved reason” from *fixed* to *worksforme* without any explanation? This just created noise, and is additionally in my opinion incorrect.
Comment 11 Xisco Faulí 2017-07-13 08:02:11 UTC
Setting it to RESOLVED FIXED is incorrect too. RESOLVED FIXED is only used when the commit fixing the problem is identified.