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

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 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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]