nanogui: Thread: XOR not working for strings in FLTK

I updated my app (which used to work) to latest 0.92 nano-X (Nov. 2010)
from 2 year old 0.91+some updates and couple of problems came up, this
being one.

I am using FLTK 1.1.10, libnx 0.46 (Nov. 2010) on an embedded 16 bit
framebuffer PC based system.

The code:

    

    XSetFunction(fl_display, fl_gc, GXxor);

    XSetForeground(fl_display, fl_gc, 0xffffffff);

 

    // works

    fl_line(cur, cy, cur, cyh);

    

    // does not work

    fl_font(font, size);

    fl_draw(str, x, y);

    

    XSetFunction(fl_display, fl_gc, GXcopy);

 

The line drawing works (XORes) but string printing does not XOR, just
copies.

I updated drivers/fblin16.c with latest from Git as much as possible but
still no fix.

Which file should I look at now since something must have changed since
0.91+

Martin

 

> The line drawing works (XORes) but string printing does not XOR, just
> copies.

Martin, you're running the 0.92 official release from 11/2010 of
NXLIB and Microwindows, and line drawing XOR works, but
text drawing not, right?

The 0.92 release was cut in November from the June 2010
codebase, just before the major driver changes were made.

In 0.92, line draws use linear16_drawpixel, which implements XOR
with the APPLYOP macro.  

Text output uses two different routines, depending on whether the
text is anti-aliased (freetype/truetype), or bitmap (PCF/FNT/Core).
In both these cases, I think I had included the faster blit routines
to be used for outputting text.  This is either linear16_drawarea for
anti-aliased text, or corefont_drawtext for bitmap drawing.
I don't think the latter had XOR support, the former may not either.

The 0.92 text output tries to use the porter-duff SRCOVER compositing
operation for text output for proper anti-aliased drawing, rather than
raster operations.  I need more info about your font in order to
help.

After 0.92 was released, and currently in the git repo are heavily
rewritten routines that use a new conversion blit architecture for
all image output, including text, GrArea, images etc.  XOR is
fully supported in the blit routines, but still may be overridden by
SRCOVER for text output.  I will have to look more into this when 
I can check the source.

Regards,

Greg

Martin - 

In looking at this, there's a couple things that might have to 
change.  The initial specification for the blit output is in 
engine/font_freetype2.c::freetype2_drawtext().  There,
the blit rop is set in the parms structure as either
MWROP_BLENDFGBG for antialiased text, or 
MWROP_COPY for bitmapped text.

You will need to make sure that you've specified non-antialiased
text, as otherwise the SRCOVER (BLENDFGBG) compositing
operation will be performed.  

I will have to check the 0.92 code, but the new codebase
will end up calling GdConversionBlit which will call
engine/devblit.c::GdFindConvBlit() which will use the driver
entry point psd->BlitCopyMaskMonoByteMSB (this will
end up in linear16_drawarea in 0.92).

The  BlitCopyMaskMonoByteMSB blitter is in 
engine/convblit_mask.c::CONVBLIT_COPY_MASK_MONO()
which doesn't handle anything other than MWROP_COPY.  This will have
to case on rop != MWROP_SRCOPY and handle
the APPLYOP macro to as it is handled in
engine/convblit_frameb.c::frameblit_blit().
Kinda complicated.

I think you will have to change the parms.op = MWROP_COPY
to something like "parms.op = gr_mode;" in font_freetype2.c. This will
use the current raster ops mode when it finally gets to the
blitter.

It might be best to move to the repository code, as there
are many improvements, and the drawarea entry point in 
0.92 doesn't handle XOR either.  The new code
looks tricky using #defines and static  inline functions
for speed, but ultimately the code will be borrowed
where it's already implemented in convblit_frameb.c
and put into convblit_mask.c.

Hope this makes sense, let me know if you need more help.
I may be able to find some more time towards the end of this 
week to add this all in for you, as it looks like specialized 
font draw code isn't currently handling raster ops like the
general blit code.

Regards,

Greg





I will look at it tomorrow.
Yes, I am running official 0.92 from Nov. 2010.
At the same time I also changed from freetype 1 to freetype 2
M.


-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Monday, February 07, 2011 3:35 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] XOR not working for strings in FLTK

> The line drawing works (XORes) but string printing does not XOR, just
> copies.

Martin, you're running the 0.92 official release from 11/2010 of
NXLIB and Microwindows, and line drawing XOR works, but
text drawing not, right?

The 0.92 release was cut in November from the June 2010
codebase, just before the major driver changes were made.

In 0.92, line draws use linear16_drawpixel, which implements XOR
with the APPLYOP macro.  

Text output uses two different routines, depending on whether the
text is anti-aliased (freetype/truetype), or bitmap (PCF/FNT/Core).
In both these cases, I think I had included the faster blit routines
to be used for outputting text.  This is either linear16_drawarea for
anti-aliased text, or corefont_drawtext for bitmap drawing.
I don't think the latter had XOR support, the former may not either.

The 0.92 text output tries to use the porter-duff SRCOVER compositing
operation for text output for proper anti-aliased drawing, rather than
raster operations.  I need more info about your font in order to
help.

After 0.92 was released, and currently in the git repo are heavily
rewritten routines that use a new conversion blit architecture for
all image output, including text, GrArea, images etc.  XOR is
fully supported in the blit routines, but still may be overridden by
SRCOVER for text output.  I will have to look more into this when 
I can check the source.

Regards,

Greg

I followed the code and hacked it to make it work.

The change "parms.op = MWROP_COPY" to "parms.op = gr_mode;" in
font_freetype2.c
will not work because it gets overwritten/ignored in devblit.c (in
GdConversionBlit())

So I modified the linear16_drawarea_bitmap_bytes_msb_first() in
fblin16.c.
I added 'else if (gr_mode == MWROP_XOR)' to the main 'if' 
and copied code from 'else' but changed all '= fg' to '^= fg'

This one change fixed my problem.
I am not sure if this is a 'correct' way to implement it and I leave
that up to you to decide.
Similar changes should also be considered in other functions.
Thanks,
Martin


-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Monday, February 07, 2011 7:41 PM
To: Martin Kajdas
Cc: ####@####.####
Subject: Re: [nanogui] XOR not working for strings in FLTK

Martin - 

In looking at this, there's a couple things that might have to 
change.  The initial specification for the blit output is in 
engine/font_freetype2.c::freetype2_drawtext().  There,
the blit rop is set in the parms structure as either
MWROP_BLENDFGBG for antialiased text, or 
MWROP_COPY for bitmapped text.

You will need to make sure that you've specified non-antialiased
text, as otherwise the SRCOVER (BLENDFGBG) compositing
operation will be performed.  

I will have to check the 0.92 code, but the new codebase
will end up calling GdConversionBlit which will call
engine/devblit.c::GdFindConvBlit() which will use the driver
entry point psd->BlitCopyMaskMonoByteMSB (this will
end up in linear16_drawarea in 0.92).

The  BlitCopyMaskMonoByteMSB blitter is in 
engine/convblit_mask.c::CONVBLIT_COPY_MASK_MONO()
which doesn't handle anything other than MWROP_COPY.  This will have
to case on rop != MWROP_SRCOPY and handle
the APPLYOP macro to as it is handled in
engine/convblit_frameb.c::frameblit_blit().
Kinda complicated.

I think you will have to change the parms.op = MWROP_COPY
to something like "parms.op = gr_mode;" in font_freetype2.c. This will
use the current raster ops mode when it finally gets to the
blitter.

It might be best to move to the repository code, as there
are many improvements, and the drawarea entry point in 
0.92 doesn't handle XOR either.  The new code
looks tricky using #defines and static  inline functions
for speed, but ultimately the code will be borrowed
where it's already implemented in convblit_frameb.c
and put into convblit_mask.c.

Hope this makes sense, let me know if you need more help.
I may be able to find some more time towards the end of this 
week to add this all in for you, as it looks like specialized 
font draw code isn't currently handling raster ops like the
general blit code.

Regards,

Greg

> The change "parms.op = MWROP_COPY" to "parms.op = gr_mode;" in
> font_freetype2.c will not work because it gets overwritten/ignored in 
> devblit.c (in
> GdConversionBlit())

Yes, there is more work required in the lower level driver.

> So I modified the linear16_drawarea_bitmap_bytes_msb_first() in
> fblin16.c. I added 'else if (gr_mode == MWROP_XOR)' to the main 'if'
> and copied code from 'else' but changed all '= fg' to '^= fg'

I won't be including that patch in 0.92, but will add a fix to
the new architecture in the git repo.  The new architecture
uses a raster ops library that allows for any raster op to
be performed, without having a lot of duplicated code, and
runs at high speed.

Thanks for pointing this out, and I'm glad you were able
to get it working for your needs in 0.92!

Regards,

Greg





This one change fixed my problem.
I am not sure if this is a 'correct' way to implement it and I leave
that up to you to decide.
Similar changes should also be considered in other functions.
Thanks,
Martin


-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Monday, February 07, 2011 7:41 PM
To: Martin Kajdas
Cc: ####@####.####
Subject: Re: [nanogui] XOR not working for strings in FLTK

Martin -

In looking at this, there's a couple things that might have to
change.  The initial specification for the blit output is in
engine/font_freetype2.c::freetype2_drawtext().  There,
the blit rop is set in the parms structure as either
MWROP_BLENDFGBG for antialiased text, or
MWROP_COPY for bitmapped text.

You will need to make sure that you've specified non-antialiased
text, as otherwise the SRCOVER (BLENDFGBG) compositing
operation will be performed.

I will have to check the 0.92 code, but the new codebase
will end up calling GdConversionBlit which will call
engine/devblit.c::GdFindConvBlit() which will use the driver
entry point psd->BlitCopyMaskMonoByteMSB (this will
end up in linear16_drawarea in 0.92).

The  BlitCopyMaskMonoByteMSB blitter is in
engine/convblit_mask.c::CONVBLIT_COPY_MASK_MONO()
which doesn't handle anything other than MWROP_COPY.  This will have
to case on rop != MWROP_SRCOPY and handle
the APPLYOP macro to as it is handled in
engine/convblit_frameb.c::frameblit_blit().
Kinda complicated.

I think you will have to change the parms.op = MWROP_COPY
to something like "parms.op = gr_mode;" in font_freetype2.c. This will
use the current raster ops mode when it finally gets to the
blitter.

It might be best to move to the repository code, as there
are many improvements, and the drawarea entry point in
0.92 doesn't handle XOR either.  The new code
looks tricky using #defines and static  inline functions
for speed, but ultimately the code will be borrowed
where it's already implemented in convblit_frameb.c
and put into convblit_mask.c.

Hope this makes sense, let me know if you need more help.
I may be able to find some more time towards the end of this
week to add this all in for you, as it looks like specialized
font draw code isn't currently handling raster ops like the
general blit code.

Regards,

Greg