In article <6719835d53.br...@helpful.demon.co.uk>, Bryan Hogan <nets...@helpful.demon.co.uk> wrote: > In message <535d31f650...@timil.com> Tim Hill <t...@timil.com> wrote:
> > In article <c089fb5c53.br...@helpful.demon.co.uk>, Bryan Hogan > > <nets...@helpful.demon.co.uk> wrote: [Snip] > > I don't think its entirely a NetSurf issue or a memory size issue but > > a processor speed > Not simply a processor speed issue No, indeed. Which is why I wrote what I did. > because the OS JPEG routines, as > used in SwiftJPEG for example, can display it at any scale in about > one second. One second? Wow. Is that to repaint the whole window? Should've bought me an Omega. This Iyonix is taking about 4 seconds with Geminus (6.5 without) to display from RAMFS (whatever the quality setting) in SwiftJPEG. I was just trying to demonstrate that NetSurf's lack of speed is not unique and various apps - such as ChangeFSI, which is 'slow' for different reasons - would be improved with a quicker clock. So would SwiftJPEG! That NetSurf doesn't seem to cache for very long a smaller version of the image that is painted into the window may seem odd but web (content management) designers shouldn't be scaling something to about 1/10 of its size to display it on a web page. I imagine that a user was never expected to post something so huge. It is, after all, over 1.3m² at 90 dpi. If the poster had posted a small version of the photo and a link to the larger one this issue would never had arisen. But then if the photographer had the opportunity to illuminate the subject better it would have been easier to examine. ;-)
