Re: New drawing/scrolling model

[Paul Davis <paul linuxaudiosystems com>]

On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson <alexl redhat com> wrote:

I've just pushed the wip/simple-draw4 branch which is the latest
version of my work trying to simplify and modernize the Gtk drawing
machinery. Its now in a state where I think its time to discuss the
merging of this.

yay!

 

Now it just invalidates the entire
scrolled area and redraws it.

completely correct. particularly when using a drawing API that may not render any pixels in memory anyway..

 

. Secondly, in a more "modern"
scene graph like in recent gtk3 most windows have alpha pixels and
render over the window background rather than each window rendering
its own opaque background, so scrolling via copy doesn't work.

which really touches on whether "simple-draw5" or some future WIP will just use a scene graph for everything anyway ...

 

A more modern way to do scrolling is to keep an offscreen buffer for
the content inside the scrolling region, covering what is currently
visible in the viewport plus a bit more. Then when we draw the window
we just draw the buffer in the right place, making scrolling very fast.
Although if you scroll to far we have to render a new piece of the
offscreen buffer.

yes. thus replicating the design of any sensible canvas implementation ...

do you have any plans to go further in this direction?

 

and finally, does simple-draw4 attempt to work hard on behalf of particular widgets, or is complexity left to the widgets? i think it is far preferable to go the latter route, although there may be a small cost of duplicated effort.