[Xquartz-dev] hi, and a few opening questions

[Jeremy Huddleston]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3040 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080216/537de55d/attachment.bin