Are XDarwin's rootless windows buffered, retained, or non-retained? Has anybody tried setting them to retained or nonretained?
XDarwin's windows are buffered. Non-retained windows don't exist as of 10.0. We currently have an extra buffer for each window, so retained windows might save memory, but coordinating CoreGraphics retained windows in one thread and X Windows' drawing in the other thread might be difficult.
How about editing the back buffer directly instead of replacing it completely when it changes? I'm more concerned about making it faster than saving memory, I'm not hitting swap.
That's harder than it used to be, given Cocoa and fb instead of Carbon and cfb. We'll probably try to do this after 4.2 is released.
We don't completely replace the back buffer; we only copy the changed pieces from the X11 buffer to the Aqua buffer.
Oh really. When I was looking at the CoreGraphics functions I didn't see any method to edit a back buffer or update a small portion. I assumed you had to import a complete bitmap each time.
Either way using nonretained windows should increase speed. It would be akin to drawing directly to the back buffer would it not? Basically using the video buffer as the back buffer.
Another thing which would help speed is marking rectangular windows as opaque.
We use CGContextDrawImage() to copy the changed bits into the back buffer. and CGContextFlush() to update the front buffer. CG tracks the dirty area of the back buffer itself.
Nonretained windows do not exist as of Mac OS X 10.0. Even if they did, they would be very difficult to integrate into the X server. The primary problem is that the X server can keep track of when the X server damages its own windows, but it can't keep track of when Aqua windows damage X windows. Synchronizing these would be hard.
Drawing directly to the video buffer may be SLOWER than drawing to buffers and then copying the buffers to the screen. It's much faster to send a single rectangle to the video card than it is to shove each individual pixel change through the graphics bus. I'm guessing this is why full-screen mode looks so slow.
All X11 windows start opaque. If they are given a shape, they are made non-opaque. If they are made rectangular again they are not changed back, because 10.0 doesn't like that.
It appears that all X11 windows aren't opaque regardless if they are given a shape or not. Do you have an example of a window which remains opaque?
An xterm in twm has no shape and should be opaque. What makes you think it's not opaque?
Because Quartz Debug says so
Are you using XDarwin 1.0a4 or the latest CVS code? 1.0a4's SHAPE support is known to be broken and may have that problem. With the latest CVS, QuartzDebug lists the never-shaped windows as opaque, as expected.
I'll wait for a5 and test again.
Does the window manager make a difference? OS X windows drag opaquely, but the Aqua title bars are always non-opaque (for obvius reasons). Even the stainless steel windows in QuickTime and iTunes which have rounded corners drag opaquely except for the corners. Is that the same with XDarwin?
Another option is to draw directly to the nonretained window like Classic does. Then X11 would have to redraw the area when a normal window passes over it causing tearing (just like Classic) but it would be much faster and use less memory.
Perhaps not to be used in all cases, but I think X11 has a direct draw mode used by apps like games. I think lxdoom looks for it.
Again: as of Mac OS X 10.0, nonretained windows are not supported. Classic uses a private API and has its own special hooks into CoreGraphics.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.