Aliased font is looking creepy

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Aliased font is looking creepy

    Hi,
    I try to use an aliased font in my application. But as soon as I use it the words get displayed very creepy. As you can see on the screenshot and the photo there are most of the pixels missing and the displayed pixels does not seem to be very aliased. The text is displayed on a window with MemDev enabled, using the text widget.

    I created the Font using the font creator and exported it in several formats but everytime without luck. I tried to use it as "Antialiased, 2bpp", "Antialiased, 4bpp" and "Extended, antialiased, 2bpp". Each font was stored as C source code and is linked at compile time. The only way my own font works is using it without antialiasing.

    Could this be a problem of the memory device setup? Or the LCD driver? My setup is as follows:
    - GUIDRV_FLEXCOLOR
    - GUICC_565
    - GUIDRV_FLEXCOLOR_F66712
    - GUIDRV_FLEXCOLOR_M16C0B16

    The second problem poped-up while creation of this thread. I used the function GUI_BMP_Serialize to create the attached screen shot. But as you can see the color is missing and also some pixels. For reference I attached a photo of the screen at the same time. Could both of these errors be linked to the same root cause?

    regards Dirk
    Images
    • Image1.png

      1.6 kB, 92×95, viewed 1,010 times
    • Image2.jpg

      95.69 kB, 429×462, viewed 862 times
  • Hello Dirk,

    The font looks as if there is no possibility to read back the display, but I see that there is a correctly drawn anti-aliased circle. If the problem would be related to the driver, the circle would look like the font. Nevertheless you should make sure your hardware is able to be read back. Of course the according function for reading the hardware should work correctly. Alternatively the emWin display driver should be configured to use a cache.

    I guess the problem is related to Memory Devices as you say. Could you please provide me with the code and the font file you used to create the screenshots. A short description of the font file would also be helpful. Could you please also tell me if the problem still occurs, when using a common MS Windows font?

    Thank you in advance.

    Best regards,
    Adrian
  • Hi Adrian,
    thank you for the quick response.

    If the memory device option for the corresponding window, that I paint on to, has been enabled, is than still a memory device for the whole LCD required? For my understanding the manual says that by using the memory device option in the window widget will create an own memory device for each window and no memory device for the LCD must be created manually. Nevertheless I will check if reading back the display is working correct.

    The circle you see on the screenshot is a picture, thats why it is so perfectly round and smooth :D

    I will try to make an example which shows the problem without too much overhead, including the font and so on. As far as I can say the font is the stock windows font tahoma, with 2bpp antialiasing (not extended) with 32 pixels height.
  • Okay let me try to summarize what I tested and which results I got.

    1.
    The read back from the display generally works. Whatever I write to the display GRAM I can read it back exactly in the same way. After another study of the manual this lead me probably to one of my problems. The display controller I use is the Himax HX8352-A, in the emWin manual this controller is not directly listed, there are listet the Himax HX8352 and the HX8352-B. My assumption was that the HX8352 of the manual is the same like the HX8352-A, is that correct?

    The thing is that the manual depicts some sort of read back configruation for the GUIDRV_FLEXCOLOR. The function GUIDRV_FlexColor_SetReadFunc66712_B16 allows three different modes to be used for conversion of the data read back. But none of the listed modes applies to my controller. My controller uses the easiest way of color coding and conversion -> none.
    Data that is written with RGB565 is also read back as RGB565. There is just one dummy read before the first pixel data can be fetched. But there is no need for three or four read cycles to get one or two pixels. like descibed in the manual for GUIDRV_FLEXCOLOR_READ_FUNC_I, GUIDRV_FLEXCOLOR_READ_FUNC_II and GUIDRV_FLEXCOLOR_READ_FUNC_III.

    So the question is, why does the GUI library convert the read data, even if it is not required? This behaviour does only apply to the Himax HX8352-B version not to the regular HX8352-A version. Is there a way stop it from doing this?

    2.
    The reading of the display does not in any way affect the drawing of the crippeled font. I faked the read data with black, white or blue data but the displayed text does not change its look. This only affects the screenshot feature. In the taken screenshot I can see the fake data/color that I have given to the GUI via the read back function. So it is pretty obvious that the "font problem" is not related to the "read back LCD problem".

    The following code displays two lines of text on the screen:

    C Source Code

    1. WM_HWIN hUSBWnd = NULL;
    2. static const GUI_WIDGET_CREATE_INFO _aUSBWin[] = {
    3. { WINDOW_CreateIndirect, "Window", GUI_ID_WNDUSB, 0, 0, 400, 240, 0, 0x00, 0 },
    4. { TEXT_CreateIndirect, "1 Text Text", GUI_ID_TXTTITLE, 20, 28, 360, 28, 0, 0x00, 0 },
    5. };
    6. static void Display_cbUSBWin(WM_MESSAGE * pMsg);
    7. void Display_CreateUSBWnd(void)
    8. {
    9. // create window hidden
    10. hUSBWnd = GUI_CreateDialogBox(_aUSBWin, GUI_COUNTOF(_aUSBWin), Display_cbUSBWin, WM_HBKWIN, 0, 0);
    11. WM_EnableMemdev(hUSBWnd);
    12. }
    13. static void Display_cbUSBWin(WM_MESSAGE * pMsg)
    14. {
    15. WM_HWIN hItem;
    16. switch(pMsg->MsgId)
    17. {
    18. case WM_INIT_DIALOG:
    19. {
    20. // Set window background color
    21. WINDOW_SetBkColor(pMsg->hWin, ARGB(0, 255, 255, 255));
    22. // Initialization of 'GUI_ID_TXTTITLE'
    23. hItem = WM_GetDialogItem(pMsg->hWin, GUI_ID_TXTTITLE);
    24. TEXT_SetFont(hItem, &GUI_Font_Tahoma28);
    25. TEXT_SetTextColor(hItem, ARGB(0, 131, 215, 0));
    26. } break;
    27. default:
    28. {
    29. WM_DefaultProc(pMsg);
    30. if(pMsg->MsgId == WM_PAINT)
    31. {
    32. GUI_SetFont(&GUI_Font_Tahoma28);
    33. GUI_SetColor(ARGB(0, 131, 215, 0));
    34. GUI_SetBkColor(ARGB(0, 255, 255, 255));
    35. GUI_DispStringAt("2 Text Text", 20, 56);
    36. }
    37. } break;
    38. } // switch
    39. }
    Display All


    The first line is drawn using the text widget and has the problem. The second line is directly drawn using a GUI function and has no problem displaying the font. Attached you will find the font that I used.
    Files
  • Hello,

    Yes, the HX8352 should be the same as the HX8352-A. The reading type can be chosen, because the display controllers which are e.g. summarized under 66712 work the same way except the read back.

    Thank you for sending the application. Unfortunately I was not able to reproduce the problem. If your problem still exists, I would recommend to contact your emWin supplier. Please note that we have an agreement with them that includes their right to provide our emWin software as library and their obligation to support their customers.

    Best regards,
    Adrian