In article <51bd896352.rogerarm(a)rogerarm.freeuk.com>,
Roger Darlington <rogerarm(a)freeuk.com> wrote:
Firstly, am I correct in thinking that the method of scrolling has
I'm not sure if you're talking about scrolling frames or scrolling the
Scrolling frames now requires the whole area to get redrawn (like it
always did for scrolling textareas, or CSS overflow:scroll blocks). It
should be possible to optimise this into a move operation and a redraw
operation for just the newly exposed area. However, this would require a
fair amount of work.
With respect to scrolling the main window, there isn't much that's changed
in years. However, the image decode and caching rules have changed, which
might affect what you're seeing. (This will affect scrolling frames and
anything else with images too.)
We used to decode all the bitmaps on a page as soon as we obtained them.
Now we only decode them if we need to plot them. Also we used never to
drop converted images from the cache until you browsed away from the page
that showed them. Now we have various heuristics to decide whether to
drop them, but the upshot is that they may be dropped if the cache is
full, even if they are used on the current page. This would mean that the
image would need to be decoded from the compressed source if we are forced
to render it (e.g. due to scrolling).
The purpose of all this is to reduce memory usage, and time spent on
things that are never seen. For example, there's no point in decoding a
bunch of images at the bottom of a page (using CPU and memory) if you're
going to follow a link to another page having never scrolled down to see
The cost of this is that sometimes NetSurf may end up decoding an image on
a page more than once.
Anyway, if this is the cause of the issue you're having, the solution is
simple: increase the size of NetSurf's cache.
On RISC OS; Iconbar menu -> Choices... -> Cache, and set the Memory cache
size to something reasonable.
Michael Drake (tlsa) http://www.netsurf-browser.org/