nanogui: XOR not working for strings in FLTK
Subject:
Re: [nanogui] XOR not working for strings in FLTK
From:
"Greg Haerr" ####@####.####
Date:
8 Feb 2011 03:40:38 -0000
Message-Id: <019101cbc741$f093c990$6964a8c0@winXP>
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
