[Xquartz-dev] Porting XCopyArea to plain OS X
jeremyhu at apple.com
Wed May 13 08:06:37 PDT 2009
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
> 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
>> 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,
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
More information about the Xquartz-dev