(sorry, hit send too early)
On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis <p...@linuxaudiosystems.com>
wrote:
>
>
>
> On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński <tweenk...@gmail.com>
> wrote:
>
>> 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre <jstpie...@mecheye.net>:
>> > May I ask why you can't paint in the draw signal? GDK already tracks
>> > invalidated windows marked by exposes and gdk_window_invalidate_rect
>> itself.
>> > It should be as efficient as drawing in an idle handler, and also
>> cooperates
>> > with the paint clock, where we can be synchronized to a compositor's
>> redraw
>> > cycle.
>>
>> If all drawing happens in the draw signal and the document has a lot
>> of demanding effects, e.g. SVG filters, it would completely kill
>> responsiveness of the UI. The idle handler solution also allows us
>> easily move drawing to a separate thread in the near future.
>>
>
> Sorry, but I think this is seriously misguided. Have you ever looked at
> the basic structure of the GTK event loop?
>
> while (1) {
>
while (events_pending()) {
process_events (); // queues redraw requests
}
if (higher-than-draw-priority-idle-callbacks) {
call_them ();
}
if (redraws_queued) {
redraw ();
}
if (lower-than-draw-priority-idle-callbacks) {
call_them ();
}
}
all you're doing by using your own idle callbacks for drawing is slightly
moving the precise point at which drawing occurs. using a separate thread
makes this even more convoluted
Now consider future (current!) GTK systems that use a frame clock. The
redraw isn't even supposed to happen on a normal idle, only one where the
frame clock indicates that it is time to draw. On such a system (which
actually reflects the real nature of video hardware for at least the last
decade or two), your redraw-on-idle is not just mildly ineffficient but
totally wrong.
as Jasper noted in his reply, but i'll describe differently: it is one
thing to draw (even in a separate thread) in a cairo surface that can later
to used during an actual redraw. and certainly many programs have excellent
reasons to do this to speed up redrawing. but this doesn't involving cairo
drawing operations on the surface derived from a GdkWindow. you are drawing
to an image surface that is basically just memory inside your process. you
can do this from any thread, at any time.
just don't actually draw it to the window anywhere except a draw event
handler. and when you need the window redrawn, just invalidate the
appropriate areas of the window, and the rest will happen naturally.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
