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. On Sat, Jun 21, 2014 at 10:05 AM, Paul Davis <p...@linuxaudiosystems.com> wrote: > > > > On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort < > jean.bref...@normalesup.org> wrote: > >> >> > you're drawing on the window outside of an expose/draw event?> >> >> Yes, because using draw events presents serious performance issues. >> > > can you describe these or point to a description of them? there are > several "native" window(ing) systems where this is actually impossible to > do. > -- Jasper
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
