Re: New drawing/scrolling model
- From: Alexander Larsson <alexl redhat com>
- To: Paul Davis <paul linuxaudiosystems com>
- Cc: Søren Sandmann <sandmann cs au dk>, GTK Devel List <gtk-devel-list gnome org>
- Subject: Re: New drawing/scrolling model
- Date: Fri, 03 May 2013 12:40:48 +0200
On fre, 2013-05-03 at 05:52 -0400, Paul Davis wrote:
On Fri, May 3, 2013 at 3:02 AM, Alexander Larsson <alexl 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]