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

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

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