Search Results

Search results 1-20 of 430.

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

  • Hi, What you are describing sounds like flickering, which is normal behavior when the display is updated frequently and there is no multi buffering or display cache enabled. Which display driver are you using? Some drivers support a caching mode that reduces the flickering. Alternatively, there is also caching handled by the window manager based on memory devices. This can be enabled by calling WM_SetCreateFlags(WM_CF_MEMDEV) after GUI_Init() and before creating any windows. Best regards, Floria…

  • Hi, Currently such a touch screen setup is not handled automatically by emWin. You would have to manually handle the input to these buttons. In your PIDConf.c (the touch screen interface), you would send the touch input events normally to emWin if they are inside the boundaries of the display. This is done with GUI_PID_StoreState(). If they are not inside the boundaries, you can check if one of the buttons is pressed and handle this input however you need to. You could e.g. send a custom message…

  • Hi Ravi, There is no such limitation. However, hundreds or even thousands of widgets on the same screen will have a big impact on performance. Because all the widgets that are visible will be drawn, so this will have huge impact on performance. In the PC environment, and on the hardware target this would be even more noticeable. Could you go a bit more into detail about what you are trying to do? I'm sure we can find a way that isn't so resource-heavy. Best regards, Florian

  • Hi, It seems like you make no use of the "Off" parameter. It is crucial that you set the file pointer to the given offset, before reading any file data to the buffer. What happens if you do that in your _GetData routine? Best regards, Florian

  • 1920x1080 not ok

    SEGGER - Florian - - emWin related

    Post

    Hi, There is no such limitation to the frame buffer size. Both sizes worked for me in an emWin simulation project. Of course, RAM can be a limiting factor. Because the display driver GUIDRV_Lin uses a frame buffer located in RAM and GUIDRV_FlexColor (when used with caching) allocates a cache in the GUI heap. Could you go more into detail about your setup (Simulation or target?, which display driver, ...)? It would help if you could provide your GUIConf.c/.h and LCDConf.c/.h files. What happens i…

  • Hi Andreas, I'm afraid this is not so easily done. Unfortunately, the streamed bitmap header does not contain the USE_ARGB flag. Also, the bitmap created by GUI_CreateBitmapFromStream() references a specific bitmap function table based on the format read from the streamed bitmap header. E.g., if the format M8888I was read from the file, then the function table GUI_DRAW_BMPM8888I is set to the GUI_BITMAP. These bitmap functions use the ARGB/ABGR format determined by the preprocessor option GUI_US…

  • Hi Andreas, The bitmaps were probably converted when the ABGR format was used. So the colors in the bitmap are still in the ABGR format. You have to re-convert the bitmaps to .DTA with the Bitmap Converter again, but with "Save colors in ARGB mode" set in the program options. Best regards, Florian

  • Hi Ravi, There currently is no "SETFONT" job implemented that would set the font of an object. But you can set the font of the object in user code. The byte arrays generated by AppWizard are essentially just the content of XBF font files. The reason why what you were trying to do does not work is that TEXT_SetFont() expects a pointer to a GUI_FONT struct. The easiest way to change the font would be if you'd retrieve the GUI_FONT* from a TEXT widget that has the 190 font set with TEXT_GetFont(). …

  • Hi Andreas, Yes, the swapped colors look like the color format was switched from ABGR to ARGB. The folks from KEIL can probably tell you why they switched it, but I suppose they did because we recommend to use ARGB which is now the standard. Quote from Andy_AN2: “we changed in LcdConf.c: #define COLOR_CONVERSION GUICC_M565 to: #define COLOR_CONVERSION GUICC_565 ” That change should not be necessary. GUICC_M565 is already the color configuration for GUI_USE_ARGB==1. Quote from Andy_AN2: “Colors i…

  • Hi, The easiest way would indeed be to place a TEXT widget on top of the IMAGE widget. The other way would be to call the GUI_Disp... routine within a callback when reacting on a WM_PAINT message. So you would manually handle the drawing of the widget. In your case you would set a custom callback to the IMAGE widget and call your drawing function after calling the default IMAGE callback to ensure that the image is still drawn normally. C Source Code (10 lines) In our wiki you can find a simple e…

  • Hi, Which emWin version are you using? And could you please share a code snippet to reproduce this behavior? Thanks and best regards, Florian

  • Max Size of TTF Font

    SEGGER - Florian - - emWin related

    Post

    Hi Martin, Our TTF module uses FreeType's caching sub-system, which also uses 8bit variables to store height and width of character glyph bitmaps (see the struct members "height" and "width" of FTC_SBitRec). FreeType is able to render glyphs bigger than 255px without the cache system, just by using the normal FreeType API. Our TTF code also renders without a cache when the font is emboldened or obliqued. But again, because emWin's font structure limits the height to 255px, it's not possible to d…

  • Max Size of TTF Font

    SEGGER - Florian - - emWin related

    Post

    Hi Mali, The font size of a GUI_FONT is limited to 255 because the font height is stored in an unsigned char (8 bits). The same is true for fonts generated with the FreeType engine. However, FreeType only allows to request a given pixel size instead of setting a pixel size directly. It entirely depends on the metrics of the font which pixel size will be actually used. This behavior is explained in more detail in the FreeType documentation. I'm assuming that when you request a size of 140px, the …

  • Hi Amol, Your implementation of the GetData() function is incorrect. That function is normally used for reading a file into the buffer pointed to by ppData. So in this case you would still have to copy the PNG data into the buffer, not just set the pointer. Below is a working implementation for reading the file from a C array: C Source Code (10 lines)But as said, this function interface is mainly for reading the PNG from a file system. If you have the converted PNG file as a C array, you can use…

  • Hi Martin, You can try to update to FreeType 2.13.2 but we have not tested this version yet, so I cannot give you any kind of warranty for it to work with our glue code. The latest version that we ship with our glue code is 2.13. I would recommend using this version, also because the fixes of 2.13.1 and 2.13.2 only seem to be minor. Best regards, Florian

  • Hi, Which emWin version are you using? The MOVIE code prior to emWin V6.30 (before the release of the MOVIE widget) did not work with the window manager. Which means the movie frames were not clipped when drawn in a window. This is one reason why the MOVIE widget has been added, which through the window manager does the clipping automatically. If your version is older than V6.30 I would suggest updating and using the MOVIE widget. I hope this helps. Best regards, Florian

  • Hi Martin, Thanks for letting us know. We got reports about the poor cache performance very shortly after we updated to FT 2.12.1. So we immediately updated to FT 2.13 as soon as we could. You can download the library with the emWin glue code on our website. Since emWin V632b, FreeType 2.13 is used. Best regards, Florian

  • Hi Miren, In your LCDConf.c in line 1039 call to GUI_DCACHE_SetClearCacheHook() is commented out. You would have to set this hook function so that the data cache will be cleared. Then, you need also need to add a call to GUI_DCACHE_Clear() at the beginning of _DMA_ExecOperation(). This should prevent the artifacts that you are seeing on your screen. Best regards, Florian

  • AppWizard Custom Keypad

    SEGGER - Florian - - emWin related

    Post

    Hi Ravi, Attached I have the code for the numpad layout. In the manual there is a detailed explanation of what the layout is composed of. You will have to rearrange the character codes in the given arrays to what you require. You can also remove lines of keys that you don't require, like the arithmetic operators. You would just remove the _Arithmetic array from the KEYDEF_LINE array. Important to note is that the sizes are not absolute. They are in promille and scale to the current window size o…

  • Hi, This looks like the data cache is not cleared before a DMA2D (ChromeArt accelerator) operation. The DMA2D is disabled for rotated configurations, therefore this should only occur when the display rotation is disabled. Could you please send me your LCDConf.c? Thanks and best regards, Florian