[Xquartz-dev] Porting XCopyArea to plain OS X

[Jeremy Huddleston]

XPlugin is really a quick and dirty way for us to get access to some  
of CoreGraphics internals.  There are bits of the CoreGraphics API  
that are not public and fluctuate between OS releases.  Xplugin gives  
us an abstraction layer for these parts of the CoreGraphics API as  
well as other similar internal API that the Xserver needs access to.

xp_copy_bytes just does a CG blt/copy (one buffer to the other).    
Similarly, xp_fill_bytes just asks CG to blt/fill (set all 4byte words  
to a given value).

The buffer format conversion used to also be accelerated (in rlAccel),  
but that is now handled in by pixman.  Furthermore, it looks like only  
ppc benefitted from our image conversion acceleration since it  
required a ppc codepath.

This code came from a time when the Xserver didn't have decent blt or  
image conversion.  I think pixman's SIMD format conversion is good  
enough that we can continue using it by default.  Furthermore, if CG  
can give us an edge on the buffer format conversion, then we should  
accelerate pixman directly so cairo/quartz gets the benefit as well.

As for your "what to do for native apps" ... well the reason we need  
libXplugin is because there isn't an exposed fast path in the public  
CoreGraphics API (atleast not that I know of in Leopard).  You can  
always use libXplugin if you're hacking something together for your  
own use and don't mind if the API changes on you and you need to  
recompile (see the warning in the header file).  That being said,  
Codeweavers relies on Xplugin for their Xserver, so the API won't  
change unless both CW and Apple don't need certain functionality any  
more.

libXplugin is really *FOR* the Xserver.  If you try using it for  
something else, I won't intentionally break your app, but I won't  
support its use either.


On May 13, 2009, at 02:25, Platon Fomichev wrote:

> Dear Jeremy
>
> Here is a bit more wordy explanation about what I am interested in:
>
> First of all I am completely oblivious to internal X server code  
> structure so please bare with me. What I am looking at is at xorg- 
> server-1.4.2-apple42/hw/xquartz/xpr/xprFrame.c file where there is a  
> pointer callback structure:
> static RootlessFrameProcsRec xprRootlessProcs, where there is a  
> xp_copy_bytes function supplied as an accelerated version for  
> blitting stuff. All in all the code in xorg-server-1.4.2-apple42/hw/ 
> xquartz is heavily filled with xp_ funcs. So I guess the first  
> question is - what code I should be looking at?
>
> Next one is as follows: if not xp* funcs what technology do you use  
> to blit fast to screen? I don't think you're allocating and dropping  
> CImage's or something in that way - it's too slow, thus you're  
> probably using something to do quick drawings and you can somehow  
> get to the 'raw' pixel data for window backing store somehow. Am I  
> right? If yes, how do you do this?
>
> The last question was about not XCopyArea for X11 which is O.K. but  
> about an analogue of XCopyArea written for OS X without any X11  
> support. Suppose I am porting X11 application to pure OS X what can  
> you advise me to use to emulate XCopyArea with source being the  
> window. Here I desperately need your expertise because there does  
> not seem to be a convinient way to do so on OS X (or may be I am  
> mistaken).
>
> Last question how do I get very quickly the bitmap bits for the  
> particular window on screen? Getting it using Cocoa is very slow.  
> Using QuickDraw is not an option.. So what to do?
>
> Best regards,
>            Platon
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev