gdispGDrawStringBox, anti-aliasing and STM32 LTDC

[vrollei]

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

 

 

 

 

[Joel Bodenmann]

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.

[vrollei]

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.

[Joel Bodenmann]

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.

[vrollei]

DrawPixel  and GetPixel work fine.  Sample of gdispGDrawStringBox result is attached.

[vrollei]

Hello @Joel Bodenmann!

Any idea how to solve this issue?

Thanks in advance!

[inmarket]

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.

[Joel Bodenmann]

@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.

[vrollei]

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. 

 

[inmarket]

We will investigate. Thanks for preparing the pictures above.

[inmarket]

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.

[vrollei]

@inmarket, do you mean ugfx_2.7/demos/modules/gdisp/fonts demo?

[Joel Bodenmann]

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

[vrollei]

@inmarket, @Joel Bodenmann,

Anti-aliasing works fine with:

 #define GDISP_NEED_TEXT_WORDWRAP                 FALSE

The problem only appears if word wrapping is enabled.

[Joel Bodenmann]

That is very interesting to know. I put this on our ToDo list.

[inmarket]

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.

 

[vrollei]

@inmarket, @Joel Bodenmann, 

thanks!