Re: New drawing/scrolling model

[Alexander Larsson <alexl redhat com>]

On tor, 2013-05-02 at 18:20 -0400, Paul Davis wrote:
> On Thu, May 2, 2013 at 6:03 PM, Søren Sandmann <sandmann cs au dk>
> wrote:
>         Alexander Larsson <alexl 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.