Ticket #13095 (closed defect: fixed)
XOR mode not being respected in OSX
| Reported by: | dhyams | Owned by: | csomor |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | wxOSX (any toolkit) | Version: | |
| Keywords: | xor, graphics, drawing | Cc: | |
| Blocked By: | Patch: | no | |
| Blocking: |
Description
Cross reference to the following thread for pictures and an example Python script that demonstrates the problem: https://groups.google.com/forum/#!topic/wxpython-users/YX4OgsnKglE
In the latest version of wxwidgets (2.9.1 in at the time of writing), the XOR drawing mode is not respected. There seem to be some #defines that are misplaced or incorrect in
http://trac.wxwidgets.org/browser/wxWidgets/trunk/src/osx/carbon/graphics.cpp#L1851
And, on line http://trac.wxwidgets.org/browser/wxWidgets/trunk/src/osx/carbon/graphics.cpp#L1888, kCGBlendModeXOR needs to be kCGBlendModeExclusion. Why they act differently I have no idea, but if you dig into the include files (specifically CGContext.h), each mode has its own number (one is 11, the other is 25). Sure enough, if you make that change, the xor'ing in wxwidgets starts working again.
As far as the #defines are concerned, all of the blend modes are turned off if the mac compatibility
version is 10.4 (which it is by default). This is in
http://trac.wxwidgets.org/browser/wxWidgets/trunk/src/osx/carbon/graphics.cpp#L1851. I can't imagine this is intentional, because the blending modes work fine in wx 2.8.11. So, if as long as you ./configure the 2.9.1.1
source code with --with-macosx-version-min=10.6 (10.5 will probably
work too), that enables the blending modes again. But this problem can be fixed with proper placing of the #defines in that routine.
With these two fixes implemented, the sample script optest.py in the original post (see the cross referenced thread) returns the correct results, and rubberbanding works again.
