Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - When is XOR drawing mode used?
When is XOR drawing mode used?
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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 Smile

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 Smile

ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: 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 Smile


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?

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Page 1 of 1

 
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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.