I had almost forgotten about this old problem, as we no longer use XOR
operations directly in the normal GNUstep code. There are at least to
different issues here. First the Cocoa documentation states that
NSCompositeHighlight gets mapped to NSCompositeSourceOver just as we do
in the cairo backend. But on the other hand gui still uses this operator
as XOR, which of course wont work.
As far as I am aware we only use this in the function NSHighlightRect()
in gui and we should come up with an operation here that just inverts
the colour values. I vaguely remember some discussion on the cairo
mailing list about subtracting the current colour from white
Something like:
cairo_set_operator (cr, CAIRO_OPERATOR_DIFFERENCE);
cairo_set_source_rgb (cr, 1, 1, 1);
We should introduce a new operator for this GSCompositeXOR and implement
it with the old NSCompositeHighlight code in the other backends. Not
sure whether we should add this now in the middle of a code freeze. We
need somebody to remind us to do it afterwards though.
I just looked at the currently available composite operators in cairo
(http://cairographics.org/operators/) and they have extended a lot since
we started to use it. Maybe we should recheck some of our operator
mappings now.
Fred
On 24.01.2012 22:39, Eric Wasylishen wrote:
I get this too with GSUseGhostResize YES. It's not clear to me how
the ghost resize code in NSSplitView is supposed to work. Is that
code expecting NSHighlightRect to be a bitwise XOR where drawing the
same rect twice gives you the original image back? NSHighlightRect
doesn't appear to do that, at least with cairo.
e.g. see
http://lists.cairographics.org/archives/cairo/2004-July/001593.html
On 2012-01-24, at 8:44 AM, Riccardo Mottola wrote:
when resizing split panes we have some sort of refresh problem
where the "grey" of the moving bar just erases what's in the view.
I can verify this in Grr and its reading panes but also in Vespucci
when viewing pages with frames.