Re: Finder vs. Quartz performance.
Re: Finder vs. Quartz performance.
- Subject: Re: Finder vs. Quartz performance.
- From: "M. Uli Kusterer" <email@hidden>
- Date: Thu, 23 Dec 2004 14:43:10 +0100
At 17:03 Uhr -0500 22.12.2004, Toby Smith wrote:
Here's what I don't get. I have an ancient G3 Mac running 10.3. If I
Now, on that same machine, whose monitor is 1280x1024, with a pretty
little desktop image, I drag a window around, that window drags itself
around just great, with a shadow, keeping up with the mouse with no
problems.
So what the dilly. Does Finder use some API I'm not privy to? Is there
some magic CGContextDrawFaster() method or something? Apple has such a
great API with the Quartz stuff, but I feel like I'm missing some huge
piece of the puzzle. Or does the Finder use OpenGL, bypassing Quartz
entirely?
I'm nitpicking here, but maybe it'll be helpful in selecting the
right terms to google for when you're looking for additional
information:
This has *nothing* whatsoever to do with the Finder. Dragging
windows is the job of Carbon (in the Finder's case), and actually
moving the window (or the entire act of dragging in the case of
AppKit) is the Window Server's job.
Thus, the Finder doesn't use OpenGL at all. Rather, the window
server uses Quartz (the Quartz Compositor, or whatever it's called --
see the conceptual docs on Quartz for the nitty-gritty details). I
doubt your ancient G3 Mac uses anything beyond that, but if you're
running a Mac with a better graphics card, the Quartz Compositor uses
OpenGL (that's what's usually called "Quartz Extreme") to composite
the windows on top of each other on the screen.
To the window server, a window is basically just a pixel map
containing a rectangular image with alpha info, with an area that,
when clicked, causes it to move around. That part can be accelerated
by making the pixel map a texture, and the window a polygon with that
texture.
OTOH, the actual drawing of text or animations into the window is
still generally done in software using Quartz. So, the window
dragging speed really doesn't have much to do with how fast text
draws.
However, you can always employ caching. AppKit text drawing suffers
from its requirement to be able to cope with all kinds of text
(Japanese, Korean, Chinese, Latin, Inuk-tut (hope I spelled that
right) lots of Indian and Arabic scripts...) with different
directions, different ways to compose character sequences, decomposed
character sequences... There are lots of ways to optimize your
drawing if you know *your users* won't need any of these. The
simplest case would be when displaying numbers: You could just create
10 NSImages for the digits from 0 to 10 and draw those instead of the
actual text. If the size never changes (or is in a very restricted
range), that may be the fastest way to composite everything together.
Caching layout managers etc. may yield the same result, though you'll
get more built-in behavior, and where the above may simply fail if an
unexpected character crops up, the layout manager will only take a
tad longer, but will at least still work. From what I heard from
Apple folks on this list, they're hard at work on optimizing numerous
aspects of text drawing, so they're aware of the need to speed this
up, but they haven't yet come around to it.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden