nanogui: Thread: Re: pixmaps and XOR not working]

I have successfully ported my app from X Windows to nano-X. There are
still a couple of issues, the most important is the GR_MODE_XOR doesn't
seem to work with GrCopyArea(...). It seems to use GR_MODE_COPY
instead.
Here is the chunk of code that does the XOR.

     if ((Chart.OldPosition != NewPosition) || (oldpxm != newpxm ) ) {
         GrSetGCMode( gc, GR_MODE_XOR ) ;
         GrCopyArea( win, gc, Chart.OldPosition, DIAMONDYSTART+BORDER, 
29, 37, \
             *oldpxm, 0, 0, GR_FALSE ) ;
         GrCopyArea( win, gc, NewPosition, DIAMONDYSTART+BORDER, 29, 37, \
             *newpxm, 0, 0, GR_FALSE ) ;
         GrSetGCMode( gc, GR_MODE_COPY ) ;
         Chart.OldPosition = NewPosition ;
         oldpxm = newpxm ;
         }

There is one other place in the code that uses GrCopyArea() and XOR, and
it shows the same behavior. Different pixmaps, but the result is the
same - GR_MODE_COPY apparently.

The pixmaps that contain the sprite seem to be OK - I see the sprite in
the right place with the colors that would be correct if XORed. This is
different behavior than when I was using the X translation library where
all I saw on the screen was a horizontal black line at the top of the
area where the sprite should have been.

Maybe I can help fix this if you give me a couple of clues on where to
look.

Regards,

Jim Ham

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.819 / Virus Database: 271.1.1/2869 - Release Date: 05/11/10 23:26:00

: There is one other place in the code that uses GrCopyArea() and XOR, and
: it shows the same behavior. Different pixmaps, but the result is the
: same - GR_MODE_COPY apparently.


Jim - I thought I had sent you some help on this last week.

The problem is likely that the framebuffer you're running
doesn't implement the blit XOR opcode, and copies instead.
To debug this, I need to know the bits per pixel (bpp)
that you're screen is configured for.  From this I can
determine the driver nano-X is using.

The call chain will look like this, (go ahead and try debugging):

nanox/srvfunc.c::GrCopyArea is called.  

GrCopyArea checks its last parameter, op, to see
whether its MWROP_USE_GC_MODE.  If so, then
the op is taken from the passed gc.  If not, then
the op is used directly.  You are passing FALSE,
so this is in error.

GrCopyArea then calls engine/devdraw.c::GdBlit with the opcode.

GdBlit calls the driver Blit() entry point.  If
you're running 32bpp, this would be
drivers/fblin32.c::linear32_blit().  There is a case statement
that handles the XOR case using ApplyOp.

Hope this helps!

Regards,

Greg

Greg,

I sent the following last week, but from a different email account. 
Perhaps the list server only accepts mail from the subscribing account.

Not much has changes as far as nano-X is concerned. I'm still running on 
top of X with an up-to-date Debian squeeze. (testing). Eventually I will 
be cross-compiling to an ARM target.

I'll know more when I have digested your latest email.

Regards,

Jim Ham

Sent earlier.....
> > So far I have
> > compiled the sources from the repository and linked in libNX11 and
> > libnano-X on my development machine. All seems to work _except_ a sprite
> > that is supposed to move around the screen. This sprite is a pixmap that
> > is defined once, then XORed over the background to move it around.
> > (XORed once to make it appear, then XORed in the same place to make it
> > disappear, repeat in another place.) This doesn't seem to work at all. I
> > get a horizontal black line the width of the pixmap at the top of where
> > the pixmap should appear. That is all.
>
> It could be that the screen driver isn't implementing XOR for this
> operation.  What GrXXX function are you using to draw the sprite,
> and what bpp, truecolor/palette etc are you running?  We need to
> determine the screen driver and entry point.

Here's the chunk of code that moves the sprite. The whole app runs
unmodified with nano-X using libNX11 (so far).
         (void)XSetFunction( dpy, gc, GXxor ) ;       // set up XOR mode
         (void)XCopyArea( dpy, *oldpxm, win, gc, 0, 0, 29, 37, \
             Chart.OldPosition, DIAMONDYSTART+BORDER ) ; // remove 
existing sprite
         (void)XCopyArea( dpy, *newpxm, win, gc, 0, 0, 29, 37, \
             NewPosition, DIAMONDYSTART+BORDER ) ; // establish new sprite
         (void)XSetFunction( dpy, gc, GXcopy ) ;   // go back to default 
copy mode

I simplified the original description somewhat - there are actually
several sprites. oldpxm and newpxm in the above code just make sure that
we erase the one already on the screen, then put up the new one. This
all works with (dare I say) real X.

I've compiled microwindows with config.X11 and with the following changes:
...
# define MWPF_TRUECOLOR888  /* pixel is packed 24 bits 8/8/8 truecolor*/
...
SCREEN_PIXTYPE           = MWPF_TRUECOLOR888# X Window screen, mouse and 
kbd drivers
...
SCREEN_WIDTH             = 320
SCREEN_HEIGHT            = 240
SCREEN_DEPTH             = 8
...

Regards,

Jim Ham

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.814 / Virus Database: 271.1.1/2852 - Release Date: 05/03/10 11:27:00

: I simplified the original description somewhat - there are actually
: several sprites. oldpxm and newpxm in the above code just make sure that
: we erase the one already on the screen, then put up the new one. This
: all works with (dare I say) real X.
:
: I've compiled microwindows with config.X11 and with the following changes:
: ...
: # define MWPF_TRUECOLOR888  /* pixel is packed 24 bits 8/8/8 truecolor*/
: ...
: SCREEN_PIXTYPE           = MWPF_TRUECOLOR888# X Window screen, mouse and
: kbd drivers
: ...
: SCREEN_WIDTH             = 320
: SCREEN_HEIGHT            = 240
: SCREEN_DEPTH             = 8

I still can't make sense of the above.  Are you running on X11?
If so, then the screen depth (8) above is ignored, and the X11
server bpp is used.  If this is the case, then we need to
look at the drivers/scr_x11.c::X11_blit entry point.


If you're not running on X11, and instead running on a 8bpp system,
then I don't understand the MWPF_TRUECOLOR888.

Regards,

Greg 

:     if ((Chart.OldPosition != NewPosition) || (oldpxm != newpxm ) ) {
:         GrSetGCMode( gc, GR_MODE_XOR ) ;
:         GrCopyArea( win, gc, Chart.OldPosition, DIAMONDYSTART+BORDER, 
: 29, 37, \
:             *oldpxm, 0, 0, GR_FALSE ) ;
:         GrCopyArea( win, gc, NewPosition, DIAMONDYSTART+BORDER, 29, 37, \
:             *newpxm, 0, 0, GR_FALSE ) ;
:         GrSetGCMode( gc, GR_MODE_COPY ) ;
:         Chart.OldPosition = NewPosition ;
:         oldpxm = newpxm ;
:         }

Jim - 

Now that I know you're running on desktop X11 we can debug this.
Change the above GrCopyArea last parameter from
GR_FALSE to MWROP_USE_GC_MODE in both
calls.  This tells nano-X to use the current GC mode.

Regards,

Greg

: 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