Re: scrolling jerky

On Sun, Apr 29, 2012 at 10:21:31PM +0100, Steve Fryatt wrote:
> 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.

I've thought about this a bit in the past, and dismissed it. Certainly
if we ever want to support the horribleness of CSS-styled scroll bars.

I think my preference for now would be they remain rendered by the
core, their visual style is refined somewhat, at the core implements
several behavioral styles, so how they operate is not surprising to
users. (Ie, an option to make them work like RISC OS scroll bars in
regards to adjust clicking in the channel or adjust dragging the handle,
another option to change the positioning of up/down buttons for AmigaOS,
etc.)

B.