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

[Krzysztof Kosiński <tweenk pl gmail com>]

> On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis <paul linuxaudiosystems com>
> wrote:
> 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.

I am aware of this difference, and Inkscape already renders to
intermediate memory surfaces rather than directly to the window in the
idle callback, but due to some legacy code it also draws the finished
surface to the window in the idle callback. What currently happens is:

- draw signal received
- queue exposed areas for rendering
- render in idle handler
- draw to window in idle handler

and, as far as I understand, what needs to happen is:

- draw signal received
- queue exposed areas for rendering
- render in separate thread
- invalidate part of the window corresponding to the completed rendering
- draw result to window in the draw signal handler

The only problem we have is that the part of the code that does the
above is very old (most of it is around 10 years old) and fairly
convoluted, so this change will require some effort.

Regards, Krzysztof