Re: scrolling jerky

On 27 Apr, Rob Kendrick wrote in message
<20120427172732.GA20183@pepperfish.net>:

> On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
>
> > Cache won't help, the issue is that "core" scrolls aren't optimised, so
> > if you scroll a frame the entire contents of that frame will be redrawn
> > - even if it is only scrolled a pixel. Conversely, if you scroll using
> > the window scrollbar, the platform code handles the scroll. Usually the
> > platform code is optimised, and will "shift" the area and just redraw
> > the newly-exposed bit.
> >
> > Clearly NetSurf would benefit from some scrolling optimisation in the
> > core, but I'm not sure if it is as easy as telling the frontend code to
> > move a particular area and then redraw the newly exposed area. (not
> > least because frontends don't currently have any concept of "move a
> > particular area")
>
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.

The other addition that I've been wondering about since frames moved to the
core is a scroll-bar plotter, which frontends could implement if they didn't
want the core's default look.

>From a RISC OS perspective I think this would be best done by offering
plotter functions that just plotted the components, instead of telling the
frontend about the concept of a scroll bar, because getting the RISC OS
Window Manager to put a 'real' bar into a NetSurf window and only show the
bits that are needed would probably undo a lot of the benefits of the frames
changes. If other frontends would find it easier to delegate the whole
plotting aspect to their window managers, however, this approach would
obviously be a disadvantage.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/