vrollei Posted January 13, 2017 Report Share Posted January 13, 2017 Hi, how to get anti-aliasing work properly with gdispGDrawStringBox and LTDC driver? gfxcong.h: #define GDISP_NEED_PIXELREAD TRUE #define GDISP_NEED_ANTIALIAS TRUE Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 13, 2017 Report Share Posted January 13, 2017 Hello @vrollei and welcome to the µGFX community! First of all: The gdispFillString() and the gdispFillStringBox() functions don't require pixel read-back as one of the parameters is the background color. The other string rendering functions require pixel read-back in order to render the text anti-aliased. The STM32LTDC driver already implements pixel read-back so everything should work out of the box. Most likely you simply forgot to use a font that comes with anti-aliasing. In order to minimize the memory requirements regular fonts don't have anti-aliasing support. You can enable anti-aliasing support when converting the font. Alternatively, you can use one of the built-in fonts that support anti-aliasing. I hope that helps. Please don't hesitate to ask if you have any further questions. Link to comment Share on other sites More sharing options...
vrollei Posted January 13, 2017 Author Report Share Posted January 13, 2017 Hello, Joel! Thanks for reply! I use this font: #define GDISP_INCLUDE_FONT_DEJAVUSANS20_AA TRUE And set widget's font: dejavu_sans_20_anti_aliased = gdispOpenFont("DejaVuSans20_aa"); gwinSetFont(ghPicker, dejavu_sans_20_anti_aliased); The result is chars with white dots in the corner and around the char. gdispGFillStringBox function works fine. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 13, 2017 Report Share Posted January 13, 2017 Can you please check whether the pixel read-back is actually working? You can do that by setting a pixel to a specific color using gdispDrawPixel() and then using gdispGetPixel() to retrieve the color value again. They must be the same. If that doesn't work, then there's an issue somewhere in the driver. Link to comment Share on other sites More sharing options...
vrollei Posted January 14, 2017 Author Report Share Posted January 14, 2017 DrawPixel and GetPixel work fine. Sample of gdispGDrawStringBox result is attached. Link to comment Share on other sites More sharing options...
vrollei Posted January 16, 2017 Author Report Share Posted January 16, 2017 Hello @Joel Bodenmann! Any idea how to solve this issue? Thanks in advance! Link to comment Share on other sites More sharing options...
inmarket Posted January 16, 2017 Report Share Posted January 16, 2017 We will add it to our list of bugs to solve. Hopefully i will have time to look at it this week. What it interesting is that it is only the zeros that seem to have the problem. It doesn't appear on the 1 or the colon. Can you please confirm if the rest of the character set has the problem. The reason I ask is to determine whether it is a font or drawing problem. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 16, 2017 Report Share Posted January 16, 2017 @vrollei Sorry for the late reply, currently having too much on our plate. As @inmarket mentioned it's very interesting to see that it appears to only happen with the '0' glyph. If you could print some A - Z and 0 - 9 set of that font (and a different font) to confirm whether it's just with the '0' or not that would be very helpful. At first I thought this might be an issue with the first read-back being inaccurate which would indicate requiring a dummy read. However, this really just happens with externally connected framebuffers where the parasitic charges haven't been discharged properly. Also, this can't be the case because your manual gdispSetPixel() / gdispGetPixel() test was successful. Link to comment Share on other sites More sharing options...
vrollei Posted January 17, 2017 Author Report Share Posted January 17, 2017 Hi @inmarket, @Joel Bodenmann! This problems appears with different chars and fonts and it seams that chars look a little bit thicker compare to gdispFillStringBox. Examples are attached as pics. Link to comment Share on other sites More sharing options...
inmarket Posted January 17, 2017 Report Share Posted January 17, 2017 We will investigate. Thanks for preparing the pictures above. Link to comment Share on other sites More sharing options...
inmarket Posted January 18, 2017 Report Share Posted January 18, 2017 I have updated the font demo. @vrollei, can you please run that demo (but with GDISP_NEED_PIXELREAD set to TRUE) and show us the results. If you are using an orientation other than 0 degrees please rerun the test at different orientations. I have tested on Win32 and everything appears to work perfectly. This tells us that the problem must be driver or hardware specific. I suspect that the problem might be something to do with FMSC RAM read timings as the framebuffer is in external RAM for the STM32LTDC and the problem is looking like a pixel read-back problem. @Joel Bodenmann, can you please have a look at initialisation for those timings please. Link to comment Share on other sites More sharing options...
vrollei Posted January 18, 2017 Author Report Share Posted January 18, 2017 @inmarket, do you mean ugfx_2.7/demos/modules/gdisp/fonts demo? Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 18, 2017 Report Share Posted January 18, 2017 Yes, @inmarket updated that demo. You have to grab the latest master branch of the repository. This is the corresponding commit: https://git.ugfx.io/uGFX/uGFX/commit/9360b2725035727262df05ae720654a48d620c69 Link to comment Share on other sites More sharing options...
vrollei Posted January 18, 2017 Author Report Share Posted January 18, 2017 @inmarket, @Joel Bodenmann, Anti-aliasing works fine with: #define GDISP_NEED_TEXT_WORDWRAP FALSE The problem only appears if word wrapping is enabled. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 18, 2017 Report Share Posted January 18, 2017 That is very interesting to know. I put this on our ToDo list. Link to comment Share on other sites More sharing options...
inmarket Posted January 20, 2017 Report Share Posted January 20, 2017 Nice catch in finding that it was a word wrap problem. That was the key to solving the problem. Pull the latest repository code and the problem should go away. Link to comment Share on other sites More sharing options...
vrollei Posted January 21, 2017 Author Report Share Posted January 21, 2017 @inmarket, @Joel Bodenmann, thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now