GNOME Bugzilla – Bug 711545
gtkpixelcache: Possibly ignoring queued redraw
Last modified: 2013-11-12 04:17:52 UTC
Created attachment 259069 [details] [review] gtkpixelcache: Fix possibly ignoring queued redraw If a queue_redraw() (invalidating a region, or the whole widget) was called from the draw() call, it could get ignored if surface_dirty existed, as it would then be updated, but destroyed right at the end of the _gtk_pixel_cache_repaint(), leading the next call to _gtk_pixel_cache_draw() have its call to repaint() be a no-op (since there's no surface_dirty) and then simply draw from (non updated) surface.
I don't think calling queue_draw in ::draw handler is a kosher thing to do. Did you see this in the wild ?
Well, I happen to use it on a project of mine, which is how I noticed it. But there shouldn't be any reason for it (sometimes) not to work?
Sure. I'll let Alex review this - the pixelcache is his work.
It seems ok to me. I don't think we necessarily should have a hard guarantee that something like that will always work, but as long as it doesn't add any complexities i think we should allow it.
Attachment 259069 [details] pushed as fc8be96 - gtkpixelcache: Fix possibly ignoring queued redraw