Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

["Jasper St. Pierre" <jstpierre mecheye net>]

On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre <jstpierre mecheye net> wrote:

Honest question: which ones? The only requirement we have with Wayland is that we know when a paint has begun and when it has ended, and also the rough area of paint, so we can tell the Wayland compositor when to swap buffers, and from which rectangles.

The draw signal does this automatically, but we can expose this in other places.

I'm skeptical of the performance concerns of the draw signal. With the new paint clock system we have, draw events are throttled and locked to the compositor, so it should be faster to queue a redraw and wait until the frame is drawn, and do it all in one go. But I'm fine with changing begin_paint_region so that it no longer clears to background, if only to help people trying to port to the crazy new drawing world.

Heads-up: I went ahead and pushed a branch for this at https://git.gnome.org/browse/gtk+/log/?h=wip/paint-stack-cleanup

Basically, gdk_window_begin_paint_region / gdk_window_begin_paint_rect no longer clear to the background automatically, which means you can use them out-of-band. To clear to the background explicitly, you can use gdk_window_paint_background.

Since it adds new API, I'm not going to push it to master until I can get some peer review, which likely means it won't get pushed until Monday. If you could test with this branch and let me know the results, that would be great!

I do encourage everyone to try using the "draw" event / "draw" signal again. With our recent paint clock and event throttling work from 3.8 onwards, we should be able to make it fast without having to resort to hacks like gdk_cairo_create.

Sorry for all the breakage! I really don't want to bug anybody too much, but I do want to make sure that our toolkit and all our applications can work out of the box on modern platforms like Wayland.

--
  Jasper