[Xquartz-dev] hi, and a few opening questions
eric.gouriou at pobox.com
Sat Feb 16 21:25:58 PST 2008
On Feb 16, 2008, at 1:47 PM, Paul Davis wrote:
> On Sat, 2008-02-16 at 13:43 -0800, Jordan K. Hubbard wrote:
>> On Feb 16, 2008, at 11:14 AM, Paul Davis wrote:
>>> From what I can tell, the speed issues really are in Cocoa. And it
>>> struck me that when I survey the landscape of other apps that have
>>> the kind of GUI requirements that Ardour does, I don't know of a
>>> single one that was written with Cocoa. Most modern apps in my
>>> domain are tending to use openGL for x-platform purposes. The legacy
>>> apps are using Carbon because ... well, they're legacy apps ;) Shark
>>> gives me some pretty clear indications that the use of Cocoa inside
>>> the window update process is a killer.
>> It would be interesting to see these shark traces attached to a
>> Radar. I've certainly heard very few complaints about "Cocoa being
>> slow", particularly given that "Cocoa" is an umbrella term for a
>> pretty large grab bag of technologies. Is it CoreGraphics which is
>> slow? The performance of one or more AppKit UI elements? Some of
>> other [set of] API? In any and all cases, the more detail the
>> better. Thanks!
> I'll forward one privately. Its really totally OT for this list.
Please make sure you add that information to the Radar you file.
Sending the Radar # to the list would be interesting to Apple
employees on the list.
If you haven't done so yet, use Quartz Debug to optimize your
Check for unnecessary drawings, repeated drawings of identical content
that end up deferred (blocked) due to coalesced updates (when attempting
to draw more than once per screen refresh).
It's only after those items are clean that you'll want to look for
in the drawing logic. Make sure you take a look at QuartzGL and enable
it if your drawing code
is a good fit for it. If it isn't, figure whether this could be
changed (roughly: avoid redrawing
elements from scratch on each screen update).
More information about the Xquartz-dev