|Subject:||Text drawing caches|
|Date:||Mon, 26 Jan 2004 00:22:12 +0100|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821|
Hi Alexander,I just looked through your new code for caching a few text frameworks for faster drawing. The code surely is nice, but it does not convince me that it is needed. As mostly with optimisation this adds some additional complexity and memory usage and I would like to know what we get for it.
No doubt some caching for this drawing code was needed. The most likely usage pattern here is that a cell first asks for the size of its text and than draws it. So a simple cache of size one should give a big boost at almost no addional costs. But it is hard to understand why a bigger and complexer cache could improve things much more. In your comments you say that some testing was done by people at #gnustep. Would you like to share some of the results with us? I am not so much asking for counts on cache hits and misses, this are internal data to the implementation, but for overall speed up of text drawing applications. For example, and this used to be one of Nicolas favourit examples whenever I dared to touch NSCell drawing, what about a NSOpenPanel browsing through some big directory structures. How much do we gain here?
What I do like is that you finally do the NSString drawing without building up a NSAttributedString, which was always a bit of a waste.
|[Prev in Thread]||Current Thread||[Next in Thread]|