Porting XCopyArea to plain OS X
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__
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (2)
-
Jeremy Huddleston
-
Platon Fomichev