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

[Paul Davis <paul linuxaudiosystems com>]

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

> 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

No, this is somewhat confused ...

1) Some *other* event/signal (user input, data ready, whatever) changes the state inside the application such that a redraw is required.

2) The application queues a redraw for the required areas (possibly the entire window, possibly various areas within it)

3) when the draw signal is finally received, draw something onto the surface derived from the window

Now, the question is precisely what gets drawn in step (3). If the app is using an image surface "cache", then this cache will need to be rendered. It could be rendered within the draw signal handler, and then kept around for the next draw as well, or it could have been rendered before the draw signal is received (in an idle callback or in another thread)

So what I think probably would happen in sodipodi is:

  * user input or data ready requires redraw

  * idle callback or another thread renders new image to an image surface

  * idle callback or a very carefully constructed call from another thread queues a redraw (invalidates part of the GdkWindow)

  * draw signal received

  * image surface used to render

As a counterpoint, this is what happens in Ardour:

  * user input or data ready requires redraw

  * queue a redraw (invalidates part of the GdkWindow)

  * draw signal received  (technically expose, since we're stuck in GTK+-2.x)

  * check for current cached image

         failure ? re-render cached image surface

  * render image surface to window surface

we never use an idle callback or another thread for any graphics rendering. In addition for various kinds of objects, we don't bother with cached image surfaces at all, but just render them directly from the draw/expose handler.