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

[Paul Davis <paul linuxaudiosystems com>]

On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński <tweenk pl gmail com> wrote:

2014-06-24 3:02 GMT+02:00 Jasper St. Pierre <jstpierre 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) {

 

In general, the document displayed in Inkscape cannot be drawn in one
piece; it must be rendered as a series of strips that are shown on the
screen once they are ready. Otherwise it takes far too long.

Although I heavily rewrote the lower levels of Inkscape canvas (those
dealing with SVG objects) to use Cairo and generally cleaned it up,
the upper levels, dealing with editing controls and scheduling the
rendering, are still barely changed from the Sodipodi days. It is
certainly possible to do all drawing in a draw signal, for example by
submitting an invalidate request once a piece of the drawing has
finished rendering, but it will require a nontrivial amount of work.

Regards, Krzysztof
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list