On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre <jstpie...@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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to