: The above code yielded the black horizontal lines at the top of where
: the pixmap should have been XORed. I think this line was more than 1
: scan line, probably 2. I'll have to repeat the experiment before I can
: say for sure.
:
: In native mode, after changing the last arg in GrCopyArea to
: MWROP_USE_GC_MODE, behavior is now very different. It appears that only
: the first scan line of the pixmap is XORed, the rest is discarded. This
: is pretty close to the behavior of the app when linked with libNX11.
:
: I have two places where I am using the XOR function.
:
: In the first case I'm XORing a pixmap where the first scan line is all
: black except for one non-back pixel in the center. It's possible that
: the first scan line is all black, depending one how nano-X drew into the
: pixmap. In any case now (with MWROP_USE_GC_MODE) I see no changes on the
: screen after the GrCopyArea() call.
Jim -
I've finally quickly looked at the drivers/fblin32.c::linear32_blit()
routine, and think I've found the problem. You should be using
the latest git code or snapshot tarball. In any case,
in the blit code, there are a couple of if statements,
one "if (op == MWROP_COPY)", then the next
"else if (MWROP_TO_MODE < SIMPLE_MAX)"
That's the case where the applyOp macro is used to run
the XOR. I can see that it does the macro for i=0; i<w,
but doesn't loop through height! Thus, only one line
is affected, just what you're seeing.
Add a "while (--h >= 0) { ... } around the entire code that's in the
else if condition, and you should be good to go...
I've attached a copy with this mod from the current source,
see if it works and let me know!
Regards,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org
