[Bug awt/24318] FontMetrics charsWidth performance

[abalkiss at redhat dot com]

------- Comment #3 from abalkiss at redhat dot com  2005-10-17 14:24 -------
Subject: Re:  FontMetrics charsWidth performance

Sven, 
I believe you're right.  Furthermore, the huge delays that we were
seeing in Swing text turned out to be a problem with the parameters we
were passing to this method, rather than the method itself, as I
reported on IRC.  Roman has said that this charsWidth is used a lot in
Swing text painting, so if any optimizations are possible it would help,
but it's not as important as I thought it was when I reported this bug.

I think having more than 100 strings on screen is quite reasonable
though, if you were running a small text editor, or jEdit or something
like that.

--Tony

On Fri, 2005-10-14 at 21:53 +0000, sven at physto dot se wrote:
> 
> ------- Comment #2 from sven at physto dot se  2005-10-14 21:53 -------
> Yeah, I looked into this with the Qt peers and using stringWidth (which is
> implemented directly in native), although the difference versus using
> charsWidth wasn't really signficiant.
> 
> I don't think this is a signficant bug. The benchmark test does 100,000 runs 
> of
> strings which are rather short. On my machine the run took about 24 seconds
> with the Qt peers and jamvm. Out of that, about 0.5 seconds were spent on the
> JNI call, one second on converting the input to native, and the rest spent in
> the actual toolkit fontmetric method. This cannot be improved upon
> substantially.
> 
> On the other hand, I don't feel this is slow. 24 seconds for 100,000 strings
> means an average of 0.24 microseconds per string. This is microoptimization.
> It's hard to improve on such a small number. Is it really needed? E.g. how 
> many
> strings to you have on-screen at any time? I'd say about a hundred, taking 24
> milliseconds to layout the text isn't a problem.
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24318