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 [mailto:g...@censoft.com] Sent: Monday, February 07, 2011 3:35 PM To: Martin Kajdas; nanogui@linuxhacker.org 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 --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
