In article
<out-4dcaedce.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk>,
Chris Young <chris.yo...@unsatisfactorysoftware.co.uk> wrote:
> On Wed, 11 May 2011 19:49:39 +0100, Michael Drake wrote:
> > How about if you make your nsfont_width implementation simply:
> >
> > *width = 10;
> > return true;
> That's better, down to about 3 seconds.
OK.
FWIW, the framebuffer front end doesn't implement the treeviews, so that
stuff doesn't show in those profiles. Starting the browser can be fairly
slow on RISC OS hardware too. On my Linux box, it's fast enough that I
don't notice it on the GTK front end. (But I don't use nsgtk much for
browsing, so my history, etc will be small.)
> So I need to rewrite nsfont_width to be faster, or...?
Not necessarily. The tree creation code is dreadfully inefficient.
If you put something like:
LOG((" %.*s", length, string));
in your nsfont_width, you'll probably see it measuring exactly the same
text over and over again. I noticed this when I was optimising the html
layout engine's use of nsfont_width.
I did not get the chance to look at the tree generation code to find out
why on earth it's doing that.
If you're interested, you could take a look at desktop/tree.c and possibly
desktop/tree_url_node.c to see what its doing.
I'm currently working out what I'll have to do to get frames handled by
the core. :)
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
