Re: Nervous tick
The following bytes were arranged on 26 Apr 2012 by Brian Jordan : In article 52869aceb1dhw...@talktalk.net, David H Wild dhw...@talktalk.net wrote: [Snip] It does it here on my RPC 6.20 with r13571 as long as the picture is on the screen. Moving the page so that the picture is off the display stops the flicker but moving it back restarts the flickering. Cat- pigeons On my emulated machine (details in sig) and NetSurf r13571 I see no evidence of this flickering, just the pointing hand. Can I just voice what seems to me to be the most screamingly obvious theory? Everyone seeing the flickering is using a real StrongARM RiscPC or similar. Everyone not seeing the flickering is using an Iyonix or better, or StrongARM VRPC (which has an option to go much faster than a real StrongARM). Therefore, the hourglass problem is caused by your processor not being fast enough to process whatever it is that page is doing. (PS: I don't see it on this Iyonix either.) -- __^__ === RISC OS is a work of art. Some people adore it, === / _ _ \ === others can't see the point of it, and it's really === ( ( |_| ) ) === expensive.=== \_ _/ === Martin Bazley ===
Re: Nervous tick
In article a647008752.mar...@blueyonder.co.uk, Martin Bazley martin.baz...@blueyonder.co.uk wrote: Therefore, the hourglass problem is caused by your processor not being fast enough to process whatever it is that page is doing. Well, yes, but we aim to support really slow systems. You can reproduce it on an Iyonix. If you go to 256 colours with error diffused bitmaps, scale the page to 300% or so and fill a 1680x1050 screen with a NetSurf window showing just that image, then you get the pointer flicker as reported. (Assuming animations are enabled.) The issue isn't processor speed but a NetSurf bug. We shouldn't be redrawing the JPEG over and over but we are because behind it is an animated throbber GIF, meant to show the image is loading before it loads. The animation is still there when the page is fully loaded, and it still requests that area to be redrawn. We need to avoid redraw requests from obscured content. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: scrolling jerky
On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote: On 25 Apr 2012, Michael Drake wrote: In article be1b188652.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: Scrolling very jerky on the vertical slider Please see my response to your previous scrolling thread: http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html Your google URL is the scrolling frames issue. Thanks for that Michael. I have increased the Cache from 20MB to 90MB, but there is still a very noticeable difference between scrolling the two versions of the very same page (neither of which get anywhere near 90MB it must be said...) 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) Regards Chris
Re: Nervous tick
In article a647008752.mar...@blueyonder.co.uk, Martin Bazley martin.baz...@blueyonder.co.uk wrote: Everyone seeing the flickering is using a real StrongARM RiscPC or similar. Everyone not seeing the flickering is using an Iyonix or better, or StrongARM VRPC (which has an option to go much faster than a real StrongARM). Well, I tried the link and noticed no flicker, but I use a release version, 2.8. *Real* RPC, RO 4.02, 64M RAM -- Russell Hafter - Mailing Lists rh.li...@phone.coop Need a hotel? http://www.hrs.com/?client=en__bluecustomerId=416873103 (NB This link needs Firefox to work)
