On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson <al...@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.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
