Re: Speed
In article adbc5fa551.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: On 14 Feb 2011 Michael Drake wrote: Restart NetSurf, open a browser window and resize it vertically so only the toolbar is showing. For the first test (thumbnail index) the time is around 6.7s (as opposed to 29.1s for a full height window) OK, so the reason for this is the viewfinder / vpod. On your system, actually plotting the page to the screen is expensive (as all the data needs to be transferred across to the podule). Reflowing the page wasn't taking long at all. However, reflowing the page made redrawing the entire window necessary. I've just made a change that should reduce the amount of document reflowing we do, and therefore the amount of plotting to screen. Please try r12243. I'd be interested to know the speeds you get for your test page with: A. pre-r12243 with incremental_reflow set to 1 (on) B. r12243 with incremental_reflow set to 1 (on) C. r12243 with incremental_reflow set to 0 (off) all with the same, full, window size if possible. The test page was: http://www.minimarcos.org.uk/cgi-bin/forum/Blah.pl?,b=MM,v=display,m=1296606335,s=4,highlight=#num4 Cheers, -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Speed
Hi Michael On Wed, 27 Apr 2011 15:39:23 +0100, Michael Drake wrote: However, reflowing the page made redrawing the entire window necessary. I've just made a change that should reduce the amount of document reflowing we do, and therefore the amount of plotting to screen. I know this wasn't directed at me, but since you are working on related code I'm curious about something. Images without sizes always seem to load stretched initially before they find their proper size. I can see that this will add in some additional processing for resizing images that don't need to be resized - probably causing some document reflow too. Is there any reason why they are loaded stretched instead of at their native size? I see it often on small images - the little platform icons on www.aminet.net did it before your recent change. I've just seen a couple of forum icons do the same with the new code, which is why I suspect it is only happening with images that don't have sizes specified. I'll see if I can find a URL that exhibits the problem. Chris
Re: Speed
On 27 Apr 2011 Chris Young wrote: Images without sizes always seem to load stretched initially before they find their proper size. I can see that this will add in some additional processing for resizing images that don't need to be resized - probably causing some document reflow too. Is there any reason why they are loaded stretched instead of at their native size? It looks to me as though the images are stretched to fit the Alt text. I don't like it either, especially if the image dimensions are specified. It would be better to truncate or wrap the text if it doesn't fit. -- 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
In article out-4db86571.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk, Chris Young chris.yo...@unsatisfactorysoftware.co.uk wrote: Images without sizes always seem to load stretched initially before they find their proper size. Initially, we layout the document before we have the images (unless they happen to be cached). If the document tells us what size to make an image (e.g. with img width=M height=N href=... or via CSS) then we can make the box the correct size from the start. If the document doesn't tell us what size the image will be displayed at, we need to wait until we have fetched it to set the box to the correct size. However, since we show the document before fetching the image, we have to make it some size initially. Before the image is available we show the image's alt text, so the size of any alt text becomes the (currently imageless) image box's size. Until my recent change, we always used to do the latter, ignoring an image's given dimensions. The render code always renders images to the size of the image box, regardless of the image's intrinsic dimensions. This is correct e.g. for img width=M height=N href=... where the image is to be shown at MxN, whatever the image's intrinsic dimensions. So to get back to the question, you are seeing an image plotted at the alt text box size. This is simply because something has caused that part of the document to be redrawn between the image becoming available (fetched and decoded), and the document being reflowed to give the box the correct new size. The document needs to be reflowed (i.e. have the layout code run on it again) when images without given dimensions are fetched because the presence of an image can affect the layout of other content on the document. Are scaled image plots particularly expensive on your system? It should be less common now. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Speed
In article 2a18a0ca51.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: I don't like it either, especially if the image dimensions are specified. It would be better to truncate or wrap the text if it doesn't fit. Please try r12243. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Speed
On 27 Apr 2011 Michael Drake wrote: In article 2a18a0ca51.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: I don't like it either, especially if the image dimensions are specified. It would be better to truncate or wrap the text if it doesn't fit. Please try r12243. That is a massive improvement, and it seems a lot faster too. Thank you. -- 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
In message 51ca8a0eb2t...@netsurf-browser.org Michael Drake t...@netsurf-browser.org wrote: Please try r12243. I'd be interested to know the speeds you get No objective tests (hence the unusual snip point), but I have the impression on Slashdot, The Register, etc. that r12243 is /much/ snappier than previous versions. My thanks again to you and all the NS crew! Dave
