In that case I suggest you look into other blend rules than 'SRC OVER DEST', and into using color keying.
You may be able to color key based on the solid font color, and apply alpha blend only to the antialias pixels. You want a blend rule that is based on the alpha of the destination surface. Like using: dstSurface->SetSrcBlendFunction(dstSurface, DSBF_DESTALPHA) or something. :-) It is worth looking into combinations of source and destination blend functions in cases such as this, and going beyond the simple Porter Duff rules if necessary. Chris ======================== Chris Bore BORES Signal Processing www.bores.com -----Original Message----- From: directfb-users-boun...@directfb.org [mailto:directfb-users-boun...@directfb.org] On Behalf Of Dave Craig Sent: 23 October 2009 14:35 To: chris.b...@yahoo.co.uk; Niels Roest Cc: directfb-users@directfb.org Subject: Re: [directfb-users] DrawString outline issue (Was RE: Fade outeffect) > Is the font drawing using antialiasing? Yes - and I really do want antialiasing. > In such a case, those pixels would have a different color (or alpha?) Well that's the problem. For the case where I'm drawing to a transparent background I'd like the antialiased pixels to have the same color as the source (the font color) and only their alpha to change i.e. for my test case, the color would be full scale white and the alpha would be used to do the antialising on to the transparent background. If the background is changed to becomes less transparent I'd want more and more color from the background to creep in to the antialiased edges, but when it's fully transparent I'd like none. DSRO_ANTIALIAS only seems to be referenced for a couple of GFX drivers, and not for the fallback non-hw accelerated generic driver. DaveC ........................................................................ Dave Craig Senior Software Engineer BrightSign skype: davecraig -----Original Message----- From: Chris Bore [mailto:chris_b...@yahoo.co.uk] Sent: 23 October 2009 13:27 To: Dave Craig; 'Niels Roest' Cc: directfb-users@directfb.org Subject: RE: [directfb-users] DrawString outline issue (Was RE: Fade out effect) Is the font drawing using antialiasing? This would put some mid-valued pixels around the outline, so the font looks more 'smooth'. In such a case, those pixels would have a different color (or alpha?) than you set for the font, and would leave the grey outline when you blend. I think there is a setting DSRO_ANTIALIAS that allows font rendering to use anti aliasing? You could check for this. Or, set to monochrome fonts (which I think disallow anti aliasing). Chris =================== Chris Bore BORES Signal Processing www.bores.com -----Original Message----- From: directfb-users-boun...@directfb.org [mailto:directfb-users-boun...@directfb.org] On Behalf Of Dave Craig Sent: 23 October 2009 11:23 To: Niels Roest Cc: directfb-users@directfb.org Subject: [directfb-users] DrawString outline issue (Was RE: Fade out effect) Hi Niels, Thanks for the quick response. In this example case my background does have color rgb 0x000000: Background is alpha 0x00, rgb 0x000000 Text is alpha 0xff, rgb 0xffffff The background is effectively pre-multiplied, but I get this thin grey outline of the text. From your previous posts the maths is something like this: c_result = (((255 - a_source) / 255) * c_destination) + (a_source / 255) * c_source In the example case, the resultant color should always be rgb 0xfffff with the resultant alpha varying from 0x00 to 0xff. Any pixel where the color is not 0xffffff and the alpha is not 0x000000 there will be a grey pixel. I've attached my test code which I'm using to help investigate this, it prints out the alpha and a color value for drawing an 'O' to the screen. I did try DSBLIT_DST_PREMULTIPLY does sound suitable, though I couldn't find a way to set this flag for a DrawString blit. Some of the DrawingFlags appear to apply to DrawString, but DSDRAW_DST_PREMULTIPLY isn't one of them, so that had no effect. To test whether DSBLIT_DST_PREMULTIPLY is what I required I changed fonts.c to add DSBLIT_DST_PREMULTIPLY: font->blittingflags = DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_COLORIZE | DSBLIT_DST_PREMULTIPLY; but the outline remained. I started looking at the pipeline code, but got bogged down a bit - lots to understand there... I'll continue to investigate, but let me know if you think I've got a basic mis-understanding! Thanks again, DaveC PS: I forgot to change the thread title on the initial post, my apologies. ........................................................................ Dave Craig Senior Software Engineer BrightSign skype: davecraig -----Original Message----- From: Niels Roest [mailto:ni...@directfb.org] Sent: 22 October 2009 19:21 To: Dave Craig Cc: directfb-users@directfb.org Subject: Re: [directfb-users] Fade out effect You mean your background is something like alpha 0, and rgb 0xffffff? This again has its roots in premultiplication. DirectFB assumes that your destination surface is premultiplicated. This means that your colours will always be relative to your alpha. The result is that your alpha is "bounding" the colours, so the colours are always smaller (or equal) than the alpha. With normal blitting situations this is not an issue, since there DirectFB will handle premutiplication if the source surface is not premultiplied (you need to specify this at surface creation). If you work on the background surface yourself, you have to handle this yourself too. To sort this, make sure your background has colour rgb 0x000000, or specify your destination as being non-premultiplied (but this is a costly operation), I think *DSBLIT_DST_PREMULTIPLY *is the flag to use. Hope this was clear also, grts Niels Dave Craig wrote: > Hi, > > Seeing as there have been some discussion on blitting modes here in > the last few days, I'd like to bring up an issue I had which I never > got to the bottom of. > > I've got an issue with DrawGlyph in 1.2.6 when I'm blitting to a > surface which is fully transparent. Though the destination alpha is > zero, some of the destination color seeps in during the blit of the > glyph. This is easiest seen where the background is fully transparent > black, the font color is fully opaque white and the background layer > is fully white. The result is white text on a white background but > with a light grey dotted outline of text. The light grey is the result > of the transparent black background being blended in to the foreground color. > > It may be that the destination alpha isn't being taken into account > during the blit. I've tried merging some blending changes from 1.4.x > but with no change in the net result. Is this a bug in the particular > blend implementation being called, or expected behaviour based on the > blitting flags being used (DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_COLORIZE > setup in fonts.c). Any suggestions about what might be the issue and > how to proceed would be gratefully received. > > Hope I've been clear, > > Thanks! > > Dave. > > ........................................................................ > Dave Craig > Senior Software Engineer > BrightSign > _______________________________________________ > directfb-users mailing list > directfb-users@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
