[Xquartz-dev] Porting XCopyArea to plain OS X

Jeremy Huddleston jeremyhu at apple.com
Tue May 12 20:21:12 PDT 2009


The Xplugin documentation is really just comments in the header file:

/usr/include/Xplugin.h

This is really only useful for the Xserver itself.  Currently, we're  
using pixman for 2D operations rather than acceleration provided by  
libXplugin.  Older versions of X11 used rlAccel (which interfaced with  
Xplugin / CoreGraphics) for 2D acceleration.  Newer versions of the  
server have changed and this section of the server has been updated  
past the point where the old rlAccel code was usable.  We need to  
create an EXA driver for the 2D operations that will interface with  
Xplugin or CoreGraphics directly for accelerated 2D operations.

What is wrong with XCopyArea()?  It *should* be "the right way" ...  
and it will be fast as well once we create that EXA driver (but my  
performance tests have shown that rlAccel only provided a 2x  
performance, so it's not *that* big of a performance gain and hence  
why we haven't invested any resources into it yet)

SDL uses QuickDraw for their Carbon video output and Quartz for the  
CoCoa video output.



On May 12, 2009, at 13:31, Platon Fomichev wrote:

> Dear List members
>
> I've been looking inside the XScreenSaver package to understand some  
> specifics about X11 stuff and I stumbled upon pretty big performance  
> problem in port where the author himself acknowledges he is  
> currently unaware what to do. The author replaced XCopyArea with  
> something like this
>
> If source is 'WINDOW'
>
>   // get the bits (desired sub-rectangle) out of the NSView via Cocoa.
>   //
>   NSBitmapImageRep *bm = [NSBitmapImageRep alloc];
>   [bm initWithFocusedViewRect:nsfrom];
>   unsigned char *data = [bm bitmapData];
>   int bps = [bm bitsPerSample];
>   int bpp = [bm bitsPerPixel];
>   int bpl = [bm bytesPerRow];
>   releaseme = bm;
>
> Then
>
> CGDataProviderCreateWithData(.. data .. )
> CGImageCreate
> CGContextDrawImage
>
> It's quite an overkill - check http://jwz.livejournal.com/ 
> 628118.html for more information.
>
> So the question is - what to do in order to move bits faster in  
> window backing store or whatever i.e. get as close to the real  
> buffer as possible. Lots of stuff hint as libXPlugin as a source of  
> 'acceleration' for X Server. Is there any way to get a public API  
> for it as well as documentation. May be there is some info on  
> CGBlt_copyBytes function in CoreGraphics as well?
>
> I am also quite at a loss - I looked at SDL code - they use  
> QuickDraw to get access to video buffer content, yet QuickDraw is  
> deprecated.. So what's the fastest possible memory to draw to  
> window, access and modify it's internal backing store?
>
> Best regards,
>           Stauff__
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev



More information about the Xquartz-dev mailing list