[Xquartz-dev] Porting XCopyArea to plain OS X

[Jeremy Huddleston]

I just realized I forgot to ask...

have you tried the SIMD accelerated blt in pixman?

On May 13, 2009, at 07:45, Jeremy Huddleston wrote:

> 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
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev