Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Mar 25, 2004 8:47 pm Post subject: When is XOR drawing mode used?
(figured I'd dump the question in here since one of the examples I'm looking at is now NeoJ does its XOR drawing)
From my limited knowledge, it seems that Java2D is similar to CoreGraphics in that neither has an explicit XOR drawing mode. I am in the process of figuring out how I'm going to add an XOR drawing mode to Neo and wanted to get some feedback
To my untrained eyes, it appears that any XOR drawing in the NeoJ VCL (VCLGraphics.java) is being done on a pixel by pixel basis, explicitly fetching the underlying pixel, doing the XOR of two pixel values, and putting the result back into the underlying graphics. AFAIK, this is the only approach to properly doing the XOR.
Do you know exactly when XOR is being used? I know it's used for object drags, selections and cursors, but I wanted to see if you've seen XOR drawing mode used for anything really intensive during your NeoJ development.
I'm actually thinking of doing a workaround in Neo where XOR drawing is actually a separate view layered on top of the underlying view using alpha compositing in CG...essentially XOR drawing becomes a semi-transparent overlay. I'm hoping that XOR isn't used extensively by the VCL for more serious operations...(presentation mode comes to mind)...
If it doesn't work I assume I can always do the explicit XORing thing and see where it takes me. Only problem is that raw pixel access in CG is also an expensive operation. CG is moderately vector based, so to get pixel level access requires a full composite, afaik
Posted: Fri Mar 26, 2004 9:39 am Post subject: Re: When is XOR drawing mode used?
Ed,
OPENSTEP wrote:
To my untrained eyes, it appears that any XOR drawing in the NeoJ VCL (VCLGraphics.java) is being done on a pixel by pixel basis, explicitly fetching the underlying pixel, doing the XOR of two pixel values, and putting the result back into the underlying graphics. AFAIK, this is the only approach to properly doing the XOR.
Java2D only supports XOR'ing when drawing or filling lines and shapes. It has no support for XOR'ing bitmaps or pixels.
OPENSTEP wrote:
Do you know exactly when XOR is being used? I know it's used for object drags, selections and cursors, but I wanted to see if you've seen XOR drawing mode used for anything really intensive during your NeoJ development.
XOR'ing is used in almost every method of SalGraphics except the text drawing methods. Surprisingly, drawing bitmaps is even XOR'd as well as copying areas. XOR'ing is used quite frequently to draw one object on top of another and then, when the object is moved or hidden, the entire area is XOR'd against itself to return it to the way it was. Also note that the "Invert" methods are sometimes XOR'ing operations (i.e. when drawing a tracing rectangle or the "50" bitmap).
I came to the conclusion that XOR'ing is really efficient on Windows as it is used so frequently throughout OOo.
OPENSTEP wrote:
I'm actually thinking of doing a workaround in Neo where XOR drawing is actually a separate view layered on top of the underlying view using alpha compositing in CG...essentially XOR drawing becomes a semi-transparent overlay. I'm hoping that XOR isn't used extensively by the VCL for more serious operations...(presentation mode comes to mind)...
If it doesn't work I assume I can always do the explicit XORing thing and see where it takes me. Only problem is that raw pixel access in CG is also an expensive operation. CG is moderately vector based, so to get pixel level access requires a full composite, afaik
As you may have noticed, NeoJ maintains its own backing buffer for each window and this backing buffer is what I draw to (hence all of the flushAll() calls in SalInstance::Yield()). I did this buffering because getting the bits off of the native window proved buggy and painful last year when I was first implementing NeoJ.
Which makes your timing impeccable. Having to maintain my own window buffer for each window seemed a waste of memory and I was sure is degrading performance. So, over the last week, I implemented direct drawing to the window.
What was interesting is that in most cases, performance did not change and, in some cases, performance was a lot worse. The reason appears to be that constantly creating a composite buffer and then drawing that composite buffer back to the window (the only way to XOR images, pixels, etc.) was no faster than just drawing (or editing the pixels directly) in my own backing buffer and periodically flushing my backing buffer to the window.
What was even worse was that drawing to the window caused a huge amount of flicker. You could see the OOo code drawing a white rectangle and then repainting an object over it every time you moved or resized something. My guess is that on Windows and X11, drawing operations are flushed to screen much less frequently than on Mac OS X.
Before you spend a lot of time on implementing a particular approach, you may want to drop my direct window drawing code into your NeoJ installation just to see what you might be in for if you do draw directly to the window after you implement XOR'ing. If you want it, let me know and I will send it to you. Maybe the flushing is different in Cocoa, but in Carbon Apple's recommendation to not double-buffer is just not good.
I still want to reduce the overhead of having my own backing buffer but I don't think drawing directly to the window will work due to Carbon's automatic flushing behavior. One idea I have is to replace the windows native backing buffer with a pointer to the buffer that I am already using. Then, I can control the flushing and reduce the number of backing buffers.
I think that I might be able to swap in my buffer using the SetWindowPic() function, but I haven't tried it yet. Any ideas where the native backing buffer is stored in a WindowRec or CGrafPort struct?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
