6:42 a.m.
The NetSurf web site says:
"Efficiency lies at the heart of the NetSurf engine, allowing it to
outwit the heavyweights of the web browser world. The NetSurf team
continue to squeeze more speed out of their code."
I've been doing one or two comparisons on a 300MHz Kinetic RiscPC
running OS 6.16.
Test 1 - following a link to near the bottom of a thumbnail index.
Fresco 2.13 15s
Oregano 1.10 17s
Netsurf r11515 28s
Test 2 - following a link to the latest forum post from the "top 10"
latest posts page.
Fresco 4s (when it worked properly)
Oregano 6s
Netsurf 17s
Now obviously there's a big advantage in coding in assembler for a
specific processor family rather than using C and making the code
portable, but the main reason seems to be that NetSurf is trying to
reformat the whole page over and over again, taking note of dimensions
only after the images have been downloaded. The other browsers do a
quick format observing dimensions where given, download the images and
then reformat if necessary. Oregano seems to fill in the visible part
of the window first which is a nice feature, but in the above tests I
waited for the page to finish downloading.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
6:45 a.m.
On Fri, Feb 04, 2011 at 11:42:03AM +0000, Richard Porter wrote:
The NetSurf web site says:
"Efficiency lies at the heart of the NetSurf engine, allowing it to
outwit the heavyweights of the web browser world. The NetSurf team
continue to squeeze more speed out of their code."
I've been doing one or two comparisons on a 300MHz Kinetic RiscPC
running OS 6.16.
Test 1 - following a link to near the bottom of a thumbnail index.
Fresco 2.13 15s
Oregano 1.10 17s
Netsurf r11515 28s
Test 2 - following a link to the latest forum post from the "top 10"
latest posts page.
Fresco 4s (when it worked properly)
Oregano 6s
Netsurf 17s
Now obviously there's a big advantage in coding in assembler for a
specific processor family rather than using C and making the code
portable,
I wouldn't call it an advantage. And none of the browsers you list here
are written in assembler; they're all written in C.
but the main reason seems to be that NetSurf is trying to
reformat the whole page over and over again, taking note of dimensions
only after the images have been downloaded.
Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco
or Oregano. The amount of work it is doing is an order of magnatude
greater.
The other browsers do a
quick format observing dimensions where given, download the images and
then reformat if necessary. Oregano seems to fill in the visible part
of the window first which is a nice feature, but in the above tests I
waited for the page to finish downloading.
You know where the sources are, etc...
B.
7 a.m.
On 4 Feb 2011 Rob Kendrick wrote:
> Now obviously there's a big advantage in coding in assembler
for a
> specific processor family rather than using C and making the code
> portable,
I wouldn't call it an advantage. And none of the browsers you
list here
are written in assembler; they're all written in C.
OK, so that takes away one possible reason for the difference.
> but the main reason seems to be that NetSurf is trying to
> reformat the whole page over and over again, taking note of dimensions
> only after the images have been downloaded.
Also, NetSurf implements *FAR MORE* of HTML and CSS than either
Fresco
or Oregano. The amount of work it is doing is an order of magnatude
greater.
The test pages were 'any browser' compatible so Netsurf didn't have to
do far more than the other browsers.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
7:09 a.m.
On Fri, Feb 04, 2011 at 12:00:49PM +0000, Richard Porter wrote:
> Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco
> or Oregano. The amount of work it is doing is an order of magnatude
> greater.
The test pages were 'any browser' compatible so Netsurf didn't have to
do far more than the other browsers.
As I said, you know where the sources are if you think you know better.
B.
8:29 a.m.
On 4 Feb 2011 Rob Kendrick wrote:
As I said, you know where the sources are if you think you know
better.
Point noted but I think the 'dancing around' is more of a design
problem.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
8:34 a.m.
On Fri, Feb 04, 2011 at 01:29:02PM +0000, Richard Porter wrote:
On 4 Feb 2011 Rob Kendrick wrote:
> As I said, you know where the sources are if you think you know better.
Point noted but I think the 'dancing around' is more of a design
problem.
The problem is not as simple as you appear to think it is. The
progressive relayout/reflow it does while fetching is there for good
reason. And even if it weren't doing it, NetSurf would probably still
be slower. Just because a page doesn't use any of the features NetSurf
has that Fresco etc do not does not mean that the assoicated code is
never executed, or data structures magically shrink, etc.
In the future, NetSurf should be faster; we already have plans on how
we're going to do that, and outlines for it all are on the development
wiki.
B.
7:40 a.m.
On 4 Feb, Richard Porter wrote in message
<26fe40a051.ricp(a)user.minijem.plus.com>:
On 4 Feb 2011 Rob Kendrick wrote:
> Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco
> or Oregano. The amount of work it is doing is an order of magnatude
> greater.
The test pages were 'any browser' compatible so Netsurf didn't have to do
far more than the other browsers.
I'm not sure that logically follows. NetSurf still has to know how to do
far more than the other browsers, for pages that /do/ contain more modern
features, and selective amnesia might be even more inefficient overall. (I
don't know for sure as I don't know that much about the layout engine in
NetSurf, but your logic seems faulty to me).
Also, define "any browser" compatible. These days, I'd take that to mean
lots of CSS and not Fresco-friendly; YMMV.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
8:51 a.m.
On 4 Feb 2011 Steve Fryatt wrote:
Also, define "any browser" compatible. These days, I'd
take that to mean
lots of CSS and not Fresco-friendly; YMMV.
What I mean is that they will format as intended on any browser (well
maybe not early versions of mosaic) even if it doesn't support CSS or
javascript. I am using css to enhance the appearance, but not things
like position:absolute. If I use javascript there's always an adequate
<noscript> element. That doesn't apply to third party software like
Blah, though I haven't updated it beyond version 7 for compatibility
reasons.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
6:53 a.m.
On 04/02/2011 11:42, Richard Porter wrote:
The NetSurf web site says:
"Efficiency lies at the heart of the NetSurf engine, allowing it to
outwit the heavyweights of the web browser world. The NetSurf team
continue to squeeze more speed out of their code."
I've been doing one or two comparisons on a 300MHz Kinetic RiscPC
running OS 6.16.
Test 1 - following a link to near the bottom of a thumbnail index.
[snip]
Test 2 - following a link to the latest forum post from the "top
10"
latest posts page.
[snip]
How about URLs so people can see what those pages contain? Such as CCS
elements which the older browsers will just ignore.
Now obviously there's a big advantage in coding in assembler for
a
specific processor family rather than using C and making the code
portable
Coding in assembler is a big disadvantage for any sizeable amount of
code. You wont find any modern web browser written in assembler, it
would be insane.
--
David J. Ruck
email: druck(a)druck.org.uk
phone: +44(0)7974 108301
7:03 a.m.
In article <4D4BE8BB.7040000(a)druck.org.uk>, David J. Ruck
<druck(a)druck.org.uk> wrote:
Coding in assembler is a big disadvantage for any sizeable amount of
code. You wont find any modern web browser written in assembler, it
would be insane.
Perhaps that is the only way that a programmer knows? I think that
StrongEd is written in Assembler and I don't think that Fred Graute,
the current maintainer, knows any 'C'? Or perhaps he is just insane..
:o)) Or perhaps I'm wrong..
--
Barry A.
'Don't stop doing things because you're getting old,
otherwise you'll get old because you stop doing things!'
5:38 a.m.
On Fri, Feb 04, 2011 at 12:03:17PM +0000, barry(a)e-allen.me.uk wrote:
In article <4D4BE8BB.7040000(a)druck.org.uk>, David J. Ruck
<druck(a)druck.org.uk> wrote:
> Coding in assembler is a big disadvantage for any sizeable amount of
> code. You wont find any modern web browser written in assembler, it
> would be insane.
Perhaps that is the only way that a programmer knows? I think that
StrongEd is written in Assembler and I don't think that Fred Graute,
the current maintainer, knows any 'C'? Or perhaps he is just insane..
:o)) Or perhaps I'm wrong..
Insane's it. There was /some/ reason to write applications in assembler
when all we had were 4MHz ARM2s. These days we don't, and we also have
freely-available high-quality compilers. Writing things in C is
/significantly/ easier than assember assuming it's not just some trivial
toy. And it also means your code is useful elsewhere.
Talking about the performance of NetSurf, a journalist on the Ziff Davis
Network recently said NetSurf is one of the fastest web browsers you'll
find:
http://www.zdnet.co.uk/news/desktop-apps/2011/02/04/top-10-linux-browsers...
(Although the chap is clearly confused about something, as he thinks
plug-in support is a web standards compliance issue.)
B.
8:25 a.m.
On 4 Feb 2011 David J. Ruck wrote:
On 04/02/2011 11:42, Richard Porter wrote:
> The NetSurf web site says:
>
> "Efficiency lies at the heart of the NetSurf engine, allowing it to
> outwit the heavyweights of the web browser world. The NetSurf team
> continue to squeeze more speed out of their code."
>
> I've been doing one or two comparisons on a 300MHz Kinetic RiscPC
> running OS 6.16.
>
> Test 1 - following a link to near the bottom of a thumbnail index.
[snip]
> Test 2 - following a link to the latest forum post from the
"top 10"
> latest posts page.
[snip]
How about URLs so people can see what those pages contain? Such as
CCS
elements which the older browsers will just ignore.
Test 1 has no CSS or javascript. Test 2 has some inline style elements
and javascript (http://www.minimarcos.org.uk/cgi-bin/forum/Blah.pl?,b=
MM,v=display,m=1296606335,s=4,highlight=#num4). I don't think the
javascript contributes to the formatting of the page - it's more
concerned with confirming delete requests, which obviously doesn't
work in NS.
> Now obviously there's a big advantage in coding in assembler
for a
> specific processor family rather than using C and making the code
> portable
Coding in assembler is a big disadvantage for any sizeable amount of
code. You wont find any modern web browser written in assembler, it
would be insane.
According to Rob the older browsers were written in C anyway, so
that's not a factor. I agree entirely with your second sentence for a
whole raft of reasons, but execution speed isn't one of them.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
7:11 a.m.
In article <66463fa051.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
The NetSurf web site says:
"Efficiency lies at the heart of the NetSurf engine, allowing it
to
outwit the heavyweights of the web browser world. The NetSurf team
continue to squeeze more speed out of their code."
I've been doing one or two comparisons on a 300MHz Kinetic RiscPC
running OS 6.16.
[Snip]
One thing occurs to me; you are using r11515 which is a development build
of Netsurf which has with it a warning "Notice: At any given time these
builds may be unstable or have verbose logging enabled which could
compromise performance of the browser", have you fallen foul of this?
Maybe a comparison with the most recent release version might give a
different result.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA
RISC OS 6.20
_____________________________________________________________________
9:04 a.m.
On 4 Feb 2011 Brian Jordan wrote:
One thing occurs to me; you are using r11515 which is a development
build
of Netsurf which has with it a warning "Notice: At any given time these
builds may be unstable or have verbose logging enabled which could
compromise performance of the browser", have you fallen foul of this?
Maybe a comparison with the most recent release version might give a
different result.
Good point. I've run the tests with NS 2.6. The results were:
test 1 - 48s (but 5s returning to the same page)
test 2 - 19s (also 5s on return to the page).
So the initial rendering is slower in 2.6 (much slower for the
thumbnail index) but cacheing is a lot more effective.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
4 p.m.
In article <66463fa051.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
4:55 p.m.
On 11 Feb 2011 Michael Drake wrote:
In article <66463fa051.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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.
Wow! 8s and 6s respectively - infinitely better on all counts! This
should be the default, or at least it should be in one of the
configuration subwindows.
Incremental reflow might enable you to see some images before the
whole lot are downloaded but it isn't worth the candle unless you're
running on really fast hardware.
Thanks for that.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
5:12 p.m.
On Fri, Feb 11, 2011 at 09:55:10PM +0000, Richard Porter wrote:
Incremental reflow might enable you to see some images before the
whole lot are downloaded but it isn't worth the candle unless you're
running on really fast hardware.
Or rather, "if you're running on really slow hardware" :) I seem to
recall that we chose the default value based on the performance of
machines similar to an A9 and the Iyonix. While it's almost always
slower to have it with a non-zero value, it can actually make things
seem faster because it increases the responsiveness.
B.
5:21 p.m.
In article <564212a451.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
On 11 Feb 2011 Michael Drake wrote:
> 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.
Wow! 8s and 6s respectively - infinitely better on all counts!
Interesting.
Incremental reflow might enable you to see some images before the
whole lot are downloaded but it isn't worth the candle unless you're
running on really fast hardware.
I'm not sure there isn't something strange happening on your system.
On my system (an Iyonix), your url[1] loads with incremental reflow
enabled in less than 4s.
1:
http://www.minimarcos.org.uk/cgi-bin/forum/Blah.pl?,b=MM,v=display,m=1296...
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
5:54 p.m.
On 11 Feb 2011 Michael Drake wrote:
In article <564212a451.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
> On 11 Feb 2011 Michael Drake wrote:
>> 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.
> Wow! 8s and 6s respectively - infinitely better on all counts!
Interesting.
> Incremental reflow might enable you to see some images before
the
> whole lot are downloaded but it isn't worth the candle unless you're
> running on really fast hardware.
I'm not sure there isn't something strange happening on your
system.
I hope not, but the Iyonix should be a bit faster than a RiscPC with a
Vpod (1280x1024, 16M colours if it matters).
On my system (an Iyonix), your url[1] loads with incremental reflow
enabled in less than 4s.
1:
http://www.minimarcos.org.uk/cgi-bin/forum/Blah.pl?,b=MM,v=display,m=1
296606335,s=4,highlight=#num4
Try the other test. Go to http://www.minimarcos.org.uk/galleries.html
and click on the link "Mk.VI". This takes you to the bottom of a
largish thumbnail index. It was taking a lot of time to reformat the
table, redraw the page and then reposition it to the on-page name tag
every few images.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
6:08 p.m.
In article <1ab017a451.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
Try the other test. Go to http://www.minimarcos.org.uk/galleries.html
and click on the link "Mk.VI". This takes you to the bottom of a
largish thumbnail index. It was taking a lot of time to reformat the
table, redraw the page and then reposition it to the on-page name tag
every few images.
Less than 5s with incremental reflow on.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
8:47 a.m.
On 11 Feb, Michael Drake wrote in message
<51a418f545tlsa(a)netsurf-browser.org>:
In article <1ab017a451.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
> Try the other test. Go to http://www.minimarcos.org.uk/galleries.html
> and click on the link "Mk.VI". This takes you to the bottom of a largish
> thumbnail index. It was taking a lot of time to reformat the table,
> redraw the page and then reposition it to the on-page name tag every few
> images.
Less than 5s with incremental reflow on.
I've just tried these two tests on RPCemu, which I /think/ is running at a
bit less than SA RiscPC speed on my system. I get:
Incremental Non-Incremental
URL 1: 5.7s 4.5s
URL 2: 7.7s 8.5s
I'm using a broadband connection. What processor and internet connection do
you have with the RiscPC, Richard?
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
2:20 p.m.
On 12 Feb 2011 Steve Fryatt wrote:
On 11 Feb, Michael Drake wrote in message
<51a418f545tlsa(a)netsurf-browser.org>:
> In article <1ab017a451.ricp(a)user.minijem.plus.com>,
> Richard Porter <ricp(a)minijem.plus.com> wrote:
>
>> Try the other test. Go to http://www.minimarcos.org.uk/galleries.html
>> and click on the link "Mk.VI".
>
> Less than 5s with incremental reflow on.
I've just tried these two tests on RPCemu, which I /think/ is
running at a
bit less than SA RiscPC speed on my system. I get:
Incremental Non-Incremental
URL 1: 5.7s 4.5s
URL 2: 7.7s 8.5s
I'm using a broadband connection. What processor and internet
connection do
you have with the RiscPC, Richard?
Kinetic RiscPC 300 MHz (StrongARM).
ADSL - PlusNet "up to 2Mbps". Ethernet router/switch to Unipod
interface. The page formats almost instantaneously on the Macbook with
Firefox so I don't think line speed is a significant factor.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
7:17 a.m.
On 11 Feb, Richard Porter wrote in message
<564212a451.ricp(a)user.minijem.plus.com>:
On 11 Feb 2011 Michael Drake wrote:
> 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.
Wow! 8s and 6s respectively - infinitely better on all counts! This should
be the default, or at least it should be in one of the configuration
subwindows.
Is there any reason why we wouldn't want users to mess with this option? If
not, I'll add it to the RISC OS config interface as it looks as if it could
be useful on the slower hardware.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
4:41 a.m.
In article <564212a451.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)minijem.plus.com> wrote:
On 11 Feb 2011 Michael Drake wrote:
> In article <66463fa051.ricp(a)user.minijem.plus.com>,
> Richard Porter <ricp(a)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.
Wow! 8s and 6s respectively - infinitely better on all counts!
Right, can you save the addresses of the two tests as ANT URL.
Restart NetSurf, open a browser window and resize it vertically so only
the toolbar is showing.
Then drag your ANT URLs onto the URL bar and tell me the time recorded in
the statusbar for each. Keep the pointer over the URL bar while it loads
and have incremental rendering on.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
5:37 a.m.
On 14 Feb 2011 Michael Drake wrote:
Right, can you save the addresses of the two tests as ANT URL.
Saving the page location as an ANT URL leaves off the # and everything
after it, which is probably intentional. Saving the link object as an
ANT URL does save the whole link.
Restart NetSurf, open a browser window and resize it vertically so
only
the toolbar is showing.
Then drag your ANT URLs onto the URL bar and tell me the time
recorded in
the statusbar for each. Keep the pointer over the URL bar while it loads
and have incremental rendering on.
For the first test (thumbnail index) the time is around 6.7s (as
opposed to 29.1s for a full height window); for the second test (forum
post) the time is around 5.6s. There were small variations between
runs.
Without the on-page link test 1 is about 2s faster and test 2 very
slightly faster. Interestingly, if I drag the same URL with an on-page
link a second time it is ignored but without the on-page link it is
processed.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
10:39 a.m.
In article <adbc5fa551.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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=1296...
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
1:50 p.m.
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
2:40 p.m.
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 Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
2:49 p.m.
In article <2a18a0ca51.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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/
5:15 p.m.
On 27 Apr 2011 Michael Drake wrote:
In article <2a18a0ca51.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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 Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
5:43 a.m.
On 27 Apr at 19:49, Michael Drake <tlsa(a)netsurf-browser.org> wrote:
In article <2a18a0ca51.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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.
I suspect this bear of little brain needs some assistance here:
As I understandf it, the latest version on the NetSurf download site
<http://www.netsurf-browser.org/downloads/riscos/testbuilds> is
recompiled, possibly with new version numbers, at least once a day. I
can see no mean of precisely downloading r12243. Can someone advise on
how I may do this?
--
Tim Powys-Lybbe tim(a)powys.org
for a miscellany of bygones: http://powys.org/
5:57 a.m.
On 28 Apr 2011 Tim Powys-Lybbe wrote:
On 27 Apr at 19:49, Michael Drake <tlsa(a)netsurf-browser.org>
wrote:
> In article <2a18a0ca51.ricp(a)user.minijem.plus.com>,
> Richard Porter <ricp(a)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.
I suspect this bear of little brain needs some assistance here:
As I understandf it, the latest version on the NetSurf download site
<http://www.netsurf-browser.org/downloads/riscos/testbuilds> is
recompiled, possibly with new version numbers, at least once a day. I
can see no mean of precisely downloading r12243. Can someone advise on
how I may do this?
r12243 happened to be the current dev version when I downloaded it
yesterday. If it's now been superseded I guess the new version will
still have the improvements.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
6:26 a.m.
On 28 Apr, Tim Powys-Lybbe wrote in message
<mpro.lkcwd100016oo0066.tim(a)powys.org>:
On 27 Apr at 19:49, Michael Drake <tlsa(a)netsurf-browser.org>
wrote:
> Please try r12243.
I suspect this bear of little brain needs some assistance here:
As I understandf it, the latest version on the NetSurf download site
<http://www.netsurf-browser.org/downloads/riscos/testbuilds> is
recompiled, possibly with new version numbers, at least once a day.
AFAIK it's recompiled at least once an hour, when changes made to the source
code in the repository warrant it.
I can see no mean of precisely downloading r12243. Can someone
advise on
how I may do this?
Just download the current build. You can see what rev it's up to from the
entries under "Recent SVN Activity" further down the page: as I write this,
the latest entry there is still r12243. However, as Richard says, later
builds (ie ones with higher 'r' numbers) will still contain the same changes
unless one of the developers specifically undoes them again for some reason.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
8:03 a.m.
On 28 Apr at 11:26, Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
On 28 Apr, Tim Powys-Lybbe wrote in message
<mpro.lkcwd100016oo0066.tim(a)powys.org>:
> On 27 Apr at 19:49, Michael Drake <tlsa(a)netsurf-browser.org> wrote:
>
> > Please try r12243.
>
> I suspect this bear of little brain needs some assistance here:
>
> As I understandf it, the latest version on the NetSurf download site
> <http://www.netsurf-browser.org/downloads/riscos/testbuilds> is
> recompiled, possibly with new version numbers, at least once a day.
AFAIK it's recompiled at least once an hour, when changes made to the
source code in the repository warrant it.
> I can see no mean of precisely downloading r12243. Can someone
> advise on how I may do this?
Just download the current build. You can see what rev it's up to from
the entries under "Recent SVN Activity" further down the page: as I
write this, the latest entry there is still r12243. However, as
Richard says, later builds (ie ones with higher 'r' numbers) will
still contain the same changes unless one of the developers
specifically undoes them again for some reason.
And the last sentence confirms the problem. There is no means of
actually downloading any specific revision number and instructions to do
so are plain misleading. Or do I have this wrong?
--
Tim Powys-Lybbe tim(a)powys.org
for a miscellany of bygones: http://powys.org/
8:29 a.m.
On Thu, Apr 28, 2011 at 01:03:14PM +0100, Tim Powys-Lybbe wrote:
> Just download the current build. You can see what rev it's
up to from
> the entries under "Recent SVN Activity" further down the page: as I
> write this, the latest entry there is still r12243. However, as
> Richard says, later builds (ie ones with higher 'r' numbers) will
> still contain the same changes unless one of the developers
> specifically undoes them again for some reason.
And the last sentence confirms the problem. There is no means of
actually downloading any specific revision number and instructions to do
so are plain misleading. Or do I have this wrong?
If a developer deliberately reverts a change, you most likely wouldn't
want it anyway. But such back-tracking are rare.
B.
1:41 p.m.
On 28 Apr, Tim Powys-Lybbe wrote in message
<mpro.lkd2te00002hm0068.tim(a)powys.org>:
On 28 Apr at 11:26, Steve Fryatt <lists(a)stevefryatt.org.uk>
wrote:
> Just download the current build. You can see what rev it's up to from
> the entries under "Recent SVN Activity" further down the page: as I
> write this, the latest entry there is still r12243. However, as Richard
> says, later builds (ie ones with higher 'r' numbers) will still contain
> the same changes unless one of the developers specifically undoes them
> again for some reason.
And the last sentence confirms the problem. There is no means of actually
downloading any specific revision number and instructions to do so are
plain misleading. Or do I have this wrong?
Why would you want to download r12243 specifically? You were advised to try
r12243: that version or any later one will do[1]. In effect, being told to
"try rXXXXX" means -- to all intents and purposes -- "download a new test
build and try it".
1. The only time it doesn't is if the change in question has subsequently
been undone. As Rob says: a) this isn't common, and b) if the change in
question has been reverted, you probably didn't want to test it anyway. I
only mentioned that to stop the pedants biting, but it seems to have
failed...
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
3:30 p.m.
In a mad moment - Steve Fryatt mumbled :
On 28 Apr, Tim Powys-Lybbe wrote in message
<mpro.lkd2te00002hm0068.tim(a)powys.org>:
> On 28 Apr at 11:26, Steve Fryatt <lists(a)stevefryatt.org.uk>
wrote:
>
>> Just download the current build. You can see what rev it's up to from
>> the entries under "Recent SVN Activity" further down the page: as I
>> write this, the latest entry there is still r12243. However, as Richard
>> says, later builds (ie ones with higher 'r' numbers) will still contain
>> the same changes unless one of the developers specifically undoes them
>> again for some reason.
>
> And the last sentence confirms the problem. There is no means of actually
> downloading any specific revision number and instructions to do so are
> plain misleading. Or do I have this wrong?
Why would you want to download r12243 specifically? You were advised
to try
r12243: that version or any later one will do[1]. In effect, being told to
"try rXXXXX" means -- to all intents and purposes -- "download a new test
build and try it".
I have just tried r12243 on an RPC (RO 402)and can confirm the
general (subjective) feeling that it is a fair bit faster,
except for heavily image laden pages.
Great work lads! and Thank You.
--
|) [
|)ryn [vans mail to - BrynEvans(a)bryork.freeuk.com
4:09 p.m.
On 28 Apr 2011, Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
On 28 Apr, Tim Powys-Lybbe wrote in message
<mpro.lkd2te00002hm0068.tim(a)powys.org>:
> On 28 Apr at 11:26, Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
>
> > Just download the current build. You can see what rev it's up to from
> > the entries under "Recent SVN Activity" further down the page: as I
> > write this, the latest entry there is still r12243. However, as Richard
> > says, later builds (ie ones with higher 'r' numbers) will still
contain
> > the same changes unless one of the developers specifically undoes them
> > again for some reason.
>
> And the last sentence confirms the problem. There is no means of actually
> downloading any specific revision number and instructions to do so are
> plain misleading. Or do I have this wrong?
Why would you want to download r12243 specifically? You were advised to try
r12243: that version or any later one will do[1]. In effect, being told to
"try rXXXXX" means -- to all intents and purposes -- "download a new test
build and try it".
1. The only time it doesn't is if the change in question has subsequently
been undone. As Rob says: a) this isn't common, and b) if the change in
question has been reverted, you probably didn't want to test it anyway. I
only mentioned that to stop the pedants biting, but it seems to have
failed...
Sometimes something stops working, as I keep a selection of previous revisions
I can get some idea of when this happened to try and find the cause. If other
revisions were still available it might be possible to locate the change that
was the cause, or at least in which revision it occured. We are constantly
warned that dev builds may be unstable, so, as I access the internet on a
friends computer I always leave it to auto load the latest stable version and
change to the latest dev build if I have problems with a site.
--
Erving
6:56 p.m.
On Thu, 28 Apr 2011 21:09:06 +0100, Erving wrote:
Sometimes something stops working, as I keep a selection of previous
revisions
I can get some idea of when this happened to try and find the cause. If other
revisions were still available it might be possible to locate the change that
was the cause, or at least in which revision it occured.
I see where you're coming from, but to do so would take up an awful
lot of storage space on the server, and encourage downloading of
versions we are trying to obsolete. There is no benefit to going back
to older revisions, except in specific cases where something has
broken, and even then the user ought to be reverting back to the last
stable (release) build - after submitting a bug report of course!
Usually if we know what has broken, referring to the SVN logs allows
us to pinpoint when this happened anyway, and building older revisions
ourselves is always an option if it comes to that.
Chris
6:42 a.m.
r12243 does seem quite a bit faster here as well on my trusty Risc PC. Well
done the team.
--
Chris
7:19 a.m.
Running 12243 on an Iyonix 5.16; subjectively it doesn't seem
noticeably faster than earlier versions and
http://www.dpreview.com/reviews/ still fails to format correctly, but
it's good to see development of a modern RISC OS browser continuing at
a brisk pace, so well done, keep up the good work!
George
In message <51caf82f97cvjazz(a)waitrose.com>
Chris Newman <cvjazz(a)waitrose.com> wrote:
r12243 does seem quite a bit faster here as well on my trusty Risc
PC. Well
done the team.
--
2:47 p.m.
In article
<OUT-4DB86571.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)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/
5:49 p.m.
On Wed, 27 Apr 2011 19:47:15 +0100, Michael Drake wrote:
Are scaled image plots particularly expensive on your system? It
should
be less common now.
Hardware accelerated scales aren't too bad, but if that isn't
available the alternative is very slow. This is definitely less
common now anyway, and I could see the improvement immediately.
Thanks for the explanation.
Chris
5:21 p.m.
In message <51ca8a0eb2tlsa(a)netsurf-browser.org>
Michael Drake <tlsa(a)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
7:03 a.m.
In message <51a40d4023tlsa(a)netsurf-browser.org>
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
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.
I've changed that on mine and it seems fast, however the performance
problem I find with Netsurf is that it single tasks and interferes
with sound and video replay. Are there setting that can be changed?
(I don't mind if as a result of such a change, it is a bit slower)
--
Jess
6:21 a.m.
The following bytes were arranged on 11 Feb 2011 by Michael Drake :
In article <66463fa051.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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 ==========================
2:26 p.m.
On Sun, Feb 13, 2011 at 11:21:30AM +0000, 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.
1:39 p.m.
Michael Drake wrote on 11 Feb:
Out of interest, what speed do you get if you set
"incremental_reflow" to
"0" in the Choices file?
on StrongArm RiscPC, NS r11454
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style
default setting for "incremental_reflow" ... 72s
removed this item from History list, called same page ... 147s
(according to bottom-of-screen status line, 8s download, rest of the
time "processing document")
"incremental _reflow:0" (then quit and reload NS) ... 76s
(download time 8s, rest of the time "converting 396684 bytes").
Fresco ... 22s
--
Jim Nagel www.archivemag.co.uk
4176
days inactive
4259
days old
netsurf-users@netsurf-browser.org
47 comments
17 participants
participants (17)
-
barry＠e-allen.me.uk -
Brian Jordan -
Bryn Evans -
Chris Newman -
Chris Young -
Dave Higton -
David J. Ruck -
Erving -
george -
Jess Hampshire -
Jim Nagel -
Martin Bazley -
Michael Drake -
Richard Porter -
Rob Kendrick -
Steve Fryatt -
Tim Powys-Lybbe