You can draw to a pixbuf or cairo image surface from another thread or in an idle handler, and then paint it to your window in the draw handler. That's probably the best idea, actually. This is what things like the new GtkListBox do -- cache the pixels in a pixel cache, and use that to draw to your window, synchronized with the paint clock.
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. > > 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 > -- Jasper
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
