On fre, 2013-05-03 at 05:52 -0400, Paul Davis wrote: > > > > On Fri, May 3, 2013 at 3:02 AM, Alexander Larsson <al...@redhat.com> > wrote: > things that are wide and tall ... well, they're on their > own ... > > > This is not really a problem the pixel cache knows the size of > the > "canvas" and the "viewport" so it will automatically not pick > an > unnecessarily wide/tall offscreen surface. > > > if true, then i don't see where the two dimensional multi-surface blit > issue arises. you may need to blit several surfaces along one axis, > but that is sort of the definition of the pixel cache.
Not sure which issue you mean. The current code doesn't do any kind of tiling or circular buffers, all it does is keep an offscreen of the visible area and then some extra (64 pixels). As long as we're scrolling less than 64 pixels from what we drawn the first time all we have to do when scrolling is to copy a different area of the offscreen surface to the window. However, when we scroll past the 64 pixels we currently do a copy on the offscreen surface to itself of the area that will still be "visible", and then we render the rest. This copy is an issue, since: a) It is a self-surface copy so we have to use an intermediate surface to do it b) Its not technically necessary, there are alternatives like tiles and circular buffers that avoid this copy Of course, the alternatives have a cost too. For once they make the code more complicated, but they also will render the widget hierarchy multiple times to the different tiles / parts-of-circular-buffer, and for each time we have to traverse and draw all the children of the scrolled container. For some containers this is probably ok, like the treeview as it can quickly find the affected rows to redraw, but for others its more of a problem. For instance GtkTextView only keeps a cache of the latest 2 rendered PangoLayouts, so it may relayout the text for each rendered tile. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
