r11644
Hi All I really look forward eagerly to each upgrade to NetSurf and very much appreciate the effort put in by the dedicated few, but I am more than a little baffled by the above modification. What is its purpose, please? Clearing the background to white and the redraw 'seems' to take ages. Cheers Brian
Re: Speed
The following bytes were arranged on 11 Feb 2011 by Michael Drake : In article 66463fa051.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: Test 1 - following a link to near the bottom of a thumbnail index. NetSurf r11515 28s Test 2 - following a link to the latest forum post from the top 10 latest posts page. NetSurf 17s Out of interest, what speed do you get if you set incremental_reflow to 0 in the Choices file? If your test pages have changed, please test again with the original settings first. Also out of interest, I performed a highly unscientific test (with a stopwatch) on this page: http://london-underground.blogspot.com/ incremental_reflow=1: 25s incremental_reflow=0: 20s I'll definitely be leaving it off. (Also using an Iyonix.) -- __^__ Your pet, our passion. - Purina / _ _ \ Your potential, our passion. - Microsoft, a few months later ( ( |_| ) ) \_ _/ === Martin Bazley ==
Re: r11644
In article mpro.lgk2k204hzm9s01kl.li...@stevefryatt.org.uk, Steve Fryatt li...@stevefryatt.org.uk wrote: On 13 Feb, Brian Bailey wrote in message 51a4df40f4bbai...@argonet.co.uk: I really look forward eagerly to each upgrade to NetSurf and very much appreciate the effort put in by the dedicated few, but I am more than a little baffled by the above modification. What is its purpose, please? The background needs to be cleared to a known state at some point, unless the subsequent redraw is guaranteed to fill the whole area. NetSurf's doing the job itself, which is usually far less intrusive than asking the Wimp to do it for us. I see, but in practice, from what I am seeing here, the reverse is true. I don't know the background behind r11644, but I'd imagine that there's a pretty good reason for the change. Well, yes, so I would have thought. Clearing the background to white and the redraw 'seems' to take ages. Can you give us an example site that shows this and tell us what hardware and screen mode you're using? Yes, sorry, I forgot to do that. The NetSurf homesite www.netsurf-browser.org/ springs to mind. A7000+ hardware and AKF60 256 colours 1024x768 60Hz. Again, I can't see a problem here: there's no visible flicker with the new build. Ooo, it doesn't just flicker, it hangs for at least 4 secs.
Re: r11644
On 13 Feb 2011 Steve Fryatt wrote: On 13 Feb, Brian Bailey wrote in message 51a4df40f4bbai...@argonet.co.uk: I really look forward eagerly to each upgrade to NetSurf and very much appreciate the effort put in by the dedicated few, but I am more than a little baffled by the above modification. What is its purpose, please? The background needs to be cleared to a known state at some point, unless the subsequent redraw is guaranteed to fill the whole area. NetSurf's doing the job itself, which is usually far less intrusive than asking the Wimp to do it for us. I don't know the background behind r11644, but I'd imagine that there's a pretty good reason for the change. Clearing the background to white and the redraw 'seems' to take ages. Can you give us an example site that shows this and tell us what hardware and screen mode you're using? Again, I can't see a problem here: there's no visible flicker with the new build. I'm getting this problem with my local home page which is fetched from Webjames. It is a simple html file with a background colour but no background image. NS creates the window, wipes it from top to bottom with white, pauses and then renders the page. Given that the background has to be rendered anyway, even if it defaults to white, I can't see what could possibly be gained by the initial phase. It takes over 3s to load the page whereas the previous version I downloaded took 2s. Timings for double-clicking on the html file are similar. Richard -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
font face=monospace in HTML
My experiments yesterday and today show that Netsurf ignores font attributes within HTML, e.g. font face=monospace (and all the other generic face types) are ignored, whereas the equivalent within a CSS is obeyed. Is this a deliberate design decision? Dave
Re: r11644
In article mpro.lgk2k204hzm9s01kl.li...@stevefryatt.org.uk, Steve Fryatt li...@stevefryatt.org.uk wrote: On 13 Feb, Brian Bailey wrote in message 51a4df40f4bbai...@argonet.co.uk: I really look forward eagerly to each upgrade to NetSurf and very much appreciate the effort put in by the dedicated few, but I am more than a little baffled by the above modification. What is its purpose, please? The background needs to be cleared to a known state at some point, unless the subsequent redraw is guaranteed to fill the whole area. NetSurf's doing the job itself, which is usually far less intrusive than asking the Wimp to do it for us. Without at all fully understanding what you have said, it does, to my mind, beg the question, if the Wimp is perhaps faster and perhaps more more efficient, in this case, then why ask NetSurf to do the job? Just asking! I don't know the background behind r11644, but I'd imagine that there's a pretty good reason for the change. Clearing the background to white and the redraw 'seems' to take ages. Can you give us an example site that shows this and tell us what hardware and screen mode you're using? Again, I can't see a problem here: there's no visible flicker with the new build. Ah, now I understand what I have been observing. On my machine, OS 4.02, there was a momentary flicker prior to r11644. Never gave it a thought before.
Re: font face=monospace in HTML
On 13 Feb 2011 Dave Higton wrote: My experiments yesterday and today show that Netsurf ignores font attributes within HTML, e.g. font face=monospace (and all the other generic face types) are ignored, whereas the equivalent within a CSS is obeyed. Is this a deliberate design decision? I think this is the usual problem that priority has been given to CSS over plain html and anything that is deprecated even if it's in widespread use. The size and color attributes are supported though. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: r11644
In article 51a4df40f4bbai...@argonet.co.uk, Brian Bailey bbai...@argonet.co.uk wrote: Clearing the background to white and the redraw 'seems' to take ages. Please try r11667 or later. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: r11644
On 13 Feb 2011 Michael Drake wrote: In article 51a4df40f4bbai...@argonet.co.uk, Brian Bailey bbai...@argonet.co.uk wrote: Clearing the background to white and the redraw 'seems' to take ages. Please try r11667 or later. r11668 is no better. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: r11644
In article 513201a551.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: On 13 Feb 2011 Michael Drake wrote: In article 51a4df40f4bbai...@argonet.co.uk, Brian Bailey bbai...@argonet.co.uk wrote: Clearing the background to white and the redraw 'seems' to take ages. Please try r11667 or later. Thanks Michael, that seems to be a lot better now, perhaps even a smidgen faster redraw than prior to r11644. r11668 is no better. Hi Richard, you are running OS 6.16 - yes? I think your hardware should perhaps be faster than the legacy machine that I am using. I wonder if there are other factors to be taken into account?
Re: r11644
On 13 Feb 2011 Brian Bailey wrote: In article 513201a551.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: On 13 Feb 2011 Michael Drake wrote: In article 51a4df40f4bbai...@argonet.co.uk, Brian Bailey bbai...@argonet.co.uk wrote: Clearing the background to white and the redraw 'seems' to take ages. Please try r11667 or later. Thanks Michael, that seems to be a lot better now, perhaps even a smidgen faster redraw than prior to r11644. r11668 is no better. Hi Richard, you are running OS 6.16 - yes? Correct. I think your hardware should perhaps be faster than the legacy machine that I am using. I wonder if there are other factors to be taken into account? Possibly but it's only a RiscPC of late 2001 vintage. There's still about a second delay while NS initialises the window. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On Sun, Feb 13, 2011 at 11:21:30AM +, Martin Bazley wrote: incremental_reflow=1: 25s incremental_reflow=0: 20s I'll definitely be leaving it off. (Also using an Iyonix.) Thing is, when we implemented this, you probably thought it was a significant performance improvement, and for most examples you'll only notice that it's not if you use a stop watch. B.
