[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drawing optimization question

From: Fred Kiefer
Subject: Re: Drawing optimization question
Date: Wed, 09 Mar 2005 20:52:36 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906

Nicolas Roard wrote:

Le 9 mars 05, à 17:15, Adrian Robert a écrit :


I'm drawing directly to a view, either using [NSString -drawAtPoint..] or,
say, with NSRectFill() and friends.

In addition to what you describe (flush problem?), NSString -drawAtPoint: has apparently a huge resource load, as each time you instanciate a layout manager, etc. Plus the cache size in NSStringDrawing is imho too small (we did some profiling with quentin during the fosdem using Shark, on a tableview containing lots of lines/columns, and with the current values, we had a 50% hit miss with NUM_CACHE_ENTRIES=16).

I think there are always cases, where you can construct even worse cases. But is this something bad? When we only draw something once there is no benefit in caching it. It would be rather great, if we could be sure that GNUstep tries to minimize the amount of things to draw. This is rather a drawback of this nice caching code here, that bad drawing code gets the biggest benefit from it. My favourit would be to have a cache of size one, this would allow us to measure a string first and than draw it.

I'm not sure why we care about the layout manager for NSStringDrawing -- it seems to me that you don't really want/need to bother with one in general if you're using thoses methods..

Not sure what you are suggesting here. String drawing needs most of the layout managers functionality, actually everything apart from the dynamic aspect. What are you expecting to gain by having additional code that builds up a glyph array and displays it, duplicating what the layout manager does?

When Alexander Malmberg unified this code it was one of the biggest steps in the history of GNUstep. I am not saying we should stop there. Go ahead measure performance bottlenecks and resolve them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]