After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 721480 - [regression] 3.8->3.10 scrolled window is empty
[regression] 3.8->3.10 scrolled window is empty
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-01-04 20:59 UTC by Jan Kratochvil
Modified: 2014-01-08 10:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
.c reproducer (1.32 KB, text/plain)
2014-01-04 21:00 UTC, Jan Kratochvil 		  Details
./s: no scrolling - everything OK (2.43 KB, image/png)
2014-01-04 21:00 UTC, Jan Kratochvil 		  Details
./s 500: correctly scrolling on gtk3-3.8.8-2.fc19 (2.71 KB, image/png)
2014-01-04 21:01 UTC, Jan Kratochvil 		  Details
./s 500: failed/empty window on gtk3-3.10.6-1.fc20 (2.53 KB, image/png)
2014-01-04 21:02 UTC, Jan Kratochvil 		  Details
PixelCache: Ensure clean cairo_t state in draw (1.31 KB, patch)
2014-01-08 09:47 UTC, Alexander Larsson 		committed Details | Review

Description Jan Kratochvil 2014-01-04 20:59:18 UTC 
When I run just "./s" it works fine, no scrollbars:

When I run "./s 500" then automatic scrollbars work on Fedora 19:

But the same run "./s 500" no longer works on Fedora 20, no lines get drawn anymore.
Comment 1 Jan Kratochvil 2014-01-04 21:00:23 UTC 
Created attachment 265338 [details]
.c reproducer
Comment 2 Jan Kratochvil 2014-01-04 21:00:53 UTC 
Created attachment 265339 [details]
./s: no scrolling - everything OK
Comment 3 Jan Kratochvil 2014-01-04 21:01:50 UTC 
Created attachment 265340 [details]
./s 500: correctly scrolling on gtk3-3.8.8-2.fc19
Comment 4 Jan Kratochvil 2014-01-04 21:02:28 UTC 
Created attachment 265341 [details]
./s 500: failed/empty window on gtk3-3.10.6-1.fc20
Comment 5 Jan Kratochvil 2014-01-05 08:25:43 UTC 
gtk3-3.11.2-1.fc21 still/also FAILs.
Comment 6 Jan Kratochvil 2014-01-07 22:10:42 UTC 
2df27ce7f801da92e64ed966d96c47e3f5d190e7 is the first bad commit
commit 2df27ce7f801da92e64ed966d96c47e3f5d190e7
Author: Alexander Larsson <alexl@redhat.com>
Date:   Sun Apr 21 01:54:05 2013 +0200

    Make GtkViewport use GtkPixelCache

    Since gdk_window_move() no longer uses XCopyArea all scrolling
    now re-renders everything in the window. To get performance
    back we use a GtkPixelCache to store already drawn children,
    and we when we expose the viewport we just blit the
    offscreen to the right place.

= 3.9.0 -> 3.9.2

At least I hope my application code is correct.
Comment 7 Jan Kratochvil 2014-01-07 22:18:50 UTC 
Today's commit cc6ffd0481e15659d6ec6758fa4e457a307f3137 still has the bug.
Comment 8 Alexander Larsson 2014-01-08 09:32:21 UTC 
The difference between the two cases is that you're getting a different default color. If you add
 cairo_set_source_rgb(cr, 0, 0, 0);
to set a black color then both cases work.

Its kinda bad that this changes between these cases though, i see no reason for that, as most code does cairo_save/restore() calls around rendering, and the initial color of a cairo_t is indeed black.
Comment 9 Alexander Larsson 2014-01-08 09:47:48 UTC 
Created attachment 265679 [details] [review]
PixelCache: Ensure clean cairo_t state in draw

This adds save/restore calls to the clear-to-transparent call in
the pixel cache, to avoid changing the default color of the
cairo_t. It also removes a call set_operator call that is no longer
necessary (it was trying to manually restore the state).
Comment 10 Alexander Larsson 2014-01-08 09:51:40 UTC 
Attachment 265679 [details] pushed as d079138 - PixelCache: Ensure clean cairo_t state in draw
Comment 11 Jan Kratochvil 2014-01-08 10:23:06 UTC 
You are right about my forgotten cr->set_source_rgb() and thanks for the fix.