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) {
>
> 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
>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
