On tor, 2013-05-02 at 18:20 -0400, Paul Davis wrote: > > > > On Thu, May 2, 2013 at 6:03 PM, Søren Sandmann <sandm...@cs.au.dk> > wrote: > Alexander Larsson <al...@redhat.com> writes: > > > * Try a tile-based approach for GtkPixelCache to avoid > having > > to do a same-surface copy (usign an intermediate surface) > when > > scrolling the cache. > > > An alternative to tiles is to keep track of an origin within > the > surface: > > +--------+--------------------------+ > | Bot R | Bottom left | > | | | > +--------O--------------------------+ > | Top R | Top left | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > +--------+--------------------------+ > > with the contents of the surface addressed modulo width and > height. Scrolling is then just a matter of moving that origin, > but > copying from the surface may require four separate blits. > Similarly, > rendering to some rectangle may have to be split into four > separate > operations. > > > this is where trying to be too generic hurts. > > > a given widget knows its aspect ratio. for things that are short and > wide, their "pixel cache" will consist of a set of full-height, > partial-width surfaces. > for things that are tall and narrow, their "pixel cache" will consist > of a set of full-width, partial-height caches. for things that are > short and narrow, their cache will consist of a single surface. for > 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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
