i just joined the xquartz-dev mailing list. i'm the lead developer of ardour (http://ardour.org/) which is a digital audio workstation that runs on linux and OS X. i've spent several months now working on both ardour itself and the port of GTK+ (which is the GUI toolkit that ardour uses) to Quartz. a few days ago, i finally bothered to compare the performance of ardour on Tiger when built with GTK/X11 versus its performance when built with GTK/Quartz. the difference was terrifying. the GTK/Quartz version uses twice the overall CPU cycles that the GTK/X11 one does. i started digging into this and at the moment, i am fairly convinced that its Cocoa that is the major issue. rather than bore this list with those specific issues however, what i wanted to ask was whether or not xquartz does/will/will not address the original issues that led us in search of a "native" version: drag-n-drop from non-X11 windows, and integration with the main menu bar model (neither of these are sensibly possible with the X11.app that predates Leopard). can an X11 application use these facilities without gross hacks and kludges? if not, is this expected at some point? thanks, --p
Hi Paul, This is a rather loaded question you're asking. Firstly regarding the native vs X11 performance issues. You might want to speak with folks at OpenOffice.org as I recall them mentioning this as well. Perhaps they may have some suggestions for tweaking your native build. XQuartz itself is just an X server. Most of the functionality you mention in the last paragraph is specific to the session manager or window manager (quartz-wm in out case) and has not been implemented. That being said, I very much hope that one day we will be able to have drag-and-drop between X and native apps, better integrated clipboard support, etc. There are just many more pressing issues before we can tackle this one. The menu bar feature is the one that I least expect to ever be supported. On Feb 16, 2008, at 07:12, Paul Davis wrote:
i just joined the xquartz-dev mailing list. i'm the lead developer of ardour (http://ardour.org/) which is a digital audio workstation that runs on linux and OS X.
i've spent several months now working on both ardour itself and the port of GTK+ (which is the GUI toolkit that ardour uses) to Quartz. a few days ago, i finally bothered to compare the performance of ardour on Tiger when built with GTK/X11 versus its performance when built with GTK/Quartz.
the difference was terrifying. the GTK/Quartz version uses twice the overall CPU cycles that the GTK/X11 one does. i started digging into this and at the moment, i am fairly convinced that its Cocoa that is the major issue.
rather than bore this list with those specific issues however, what i wanted to ask was whether or not xquartz does/will/will not address the original issues that led us in search of a "native" version: drag-n- drop from non-X11 windows, and integration with the main menu bar model (neither of these are sensibly possible with the X11.app that predates Leopard). can an X11 application use these facilities without gross hacks and kludges? if not, is this expected at some point?
thanks, --p
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sat, 2008-02-16 at 10:51 -0800, Jeremy Huddleston wrote:
Hi Paul,
This is a rather loaded question you're asking. Firstly regarding the native vs X11 performance issues. You might want to speak with folks at OpenOffice.org as I recall them mentioning this as well. Perhaps they may have some suggestions for tweaking your native build.
Well, since I'm one of the most active developers of the gtk/osx port right now, I think you can assume I have my hands pretty deep in the mess :) And when I say "deep", I mean right inside the window redraw cycle at the intersection of Quartz/Cocoa and GDK. My codebase actual contains a bunch of patches that we hope will get into gtk/osx eventually, since they dramatically improve performance already :)
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.
XQuartz itself is just an X server. Most of the functionality you mention in the last paragraph is specific to the session manager or window manager (quartz-wm in out case) and has not been implemented. That being said, I very much hope that one day we will be able to have drag-and-drop between X and native apps, better integrated clipboard support, etc. There are just many more pressing issues before we can tackle this one. The menu bar feature is the one that I least expect to ever be supported.
OK, thanks for the info. Just as a point of reference, the old "3rd party" X server for OS X (Ouroborous) had both these items (DnD, menubar). It had a number of other nice features too - at least on paper; I never actually tried running it. I understand that the menubar thing is tricky - all the solutions I've actually seen at work are all X11-toolkit specific, and map a native menu onto the Carbon "main menu". Since X11 has no concept of a menu, its clear that its hard to integrate this at that level. As a point of interest, given my quick grep through the xquartz code the other day: how *is* xquartz drawing the screen? Does it go via CoreGraphics/Quartz, or does it undercut that in some way? Does it blit an rgba buffer to the display, or actually use CG calls for more stuff? grep suggested to me that almost no CG calls are to be found inside the server source tree .... --p
On Feb 16, 2008, at 11:14, Paul Davis wrote:
Well, since I'm one of the most active developers of the gtk/osx port right now, I think you can assume I have my hands pretty deep in the mess :) And when I say "deep", I mean right inside the window redraw cycle at the intersection of Quartz/Cocoa and GDK. My codebase actual contains a bunch of patches that we hope will get into gtk/osx eventually, since they dramatically improve performance already :)
Awesome. I'm glad someone has their hands that deep in the pile =).
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.
I haven't really spent much time with Cocoa, myself. I've mentioned a few times on this list that I'm a C unix developer, and Cocoa/Quartz/ ObjectiveC are all new to me. Most of the hacking I've been doing has been on the "UNIX / C" side of X11 and not really ingrained in the Cocoa side of things. That being said, the major regression with 1.4 right now is deep inside our input control mechanism passing input events to Xinput from Cocoa, so I'll be walking further up this learning curve soon. I highly suggest that you file a radar ( http://bugreport.apple.com ) on this issue so someone in a position to fix performance in Cocoa knows about this issue and can work with you to fix it.
OK, thanks for the info. Just as a point of reference, the old "3rd party" X server for OS X (Ouroborous) had both these items (DnD, menubar).
Hmm... interesting. Thanks for the tip. I'll have to take a look at it (assuming it is MIT licensed).
It had a number of other nice features too - at least on paper; I never actually tried running it. I understand that the menubar thing is tricky - all the solutions I've actually seen at work are all X11-toolkit specific, and map a native menu onto the Carbon "main menu". Since X11 has no concept of a menu, its clear that its hard to integrate this at that level.
Yeah. I think there have been some "standard" ways of doing it that session managers have hooked into (mainly due to KDE's initiative to have "Apple style menu" support). We may be able to tap into that to actually bring X11 Apple Style Menus back to the XQuartz menu... but again... this is quite a ways off.
As a point of interest, given my quick grep through the xquartz code the other day: how *is* xquartz drawing the screen? Does it go via CoreGraphics/Quartz, or does it undercut that in some way? Does it blit an rgba buffer to the display, or actually use CG calls for more stuff? grep suggested to me that almost no CG calls are to be found inside the server source tree ....
Eh... hrm... this is a bunch of spaghetti to be honest. You certainly have a right to be confused. Right now (as of the very latest release), it is using pixman for the 2D rendering and GL calls are being passed directly to the native OpenGL framework. Part of the hope for 3.0 is to rebuild major sections of the DDX (possibly leveraging kdrive) using CoreGraphics/Quartz as much as possible. This was because of limitations that were in place during the initial design of X11 on OS-X (back in early Panther days). XQuartz is essentially that initial design fast-forwarded in time along X development. We've gotten it to somewhere around a year ago, and hopefully we'll be at "today" soon.
On Sat, 2008-02-16 at 11:33 -0800, Jeremy Huddleston wrote:
Shark gives me some pretty
clear indications that the use of Cocoa inside the window update process is a killer.
I haven't really spent much time with Cocoa, myself. I've mentioned a few times on this list that I'm a C unix developer, and Cocoa/Quartz/ ObjectiveC are all new to me. Most of the hacking I've been doing has been on the "UNIX / C" side of X11 and not really ingrained in the Cocoa side of things. That being said, the major regression with 1.4 right now is deep inside our input control mechanism passing input events to Xinput from Cocoa, so I'll be walking further up this learning curve soon.
I highly suggest that you file a radar ( http://bugreport.apple.com ) on this issue so someone in a position to fix performance in Cocoa knows about this issue and can work with you to fix it.
Nah, I'm an idiot :) In thinking through this some more, I realized: what happens when you remove most of the code that takes up 60% of your total CPU cycles and put it in a server? Could it be that *your* app suddenly looks about 50% faster? Did you bother to measure the overall CPU load instead of the per-process load? Well no, I haven't, but I can guess what it will show me :)
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! - Jordan
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. --p
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 drawing code. Check for unnecessary drawings, repeated drawings of identical content and drawings that end up deferred (blocked) due to coalesced updates (when attempting to draw more than once per screen refresh). <http://developer.apple.com/qa/qa2001/qa1236.html> It's only after those items are clean that you'll want to look for other inefficiencies 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). Eric
participants (4)
-
Eric Gouriou
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Paul Davis