All Activity

Excellent! Отлично!

Awesome - Thanks! This has now been merged into the master branch: https://git.ugfx.io/uGFX/ugfx/commit/02cbcea9e5b882f35b33f079340925a511b78acb Will do a v2.10 release this week.

Hi, Joel! I tested the patch for more than a day on two devices. Everything works stably as expected and there were no problems.

µGFX supports file formats like BMP, GIF and PNG out of the box. You can directly load the encoded image. No need to use an image converter. You can use the NATIVE format but then you'll indeed have to do the conversion yourself. The easiest way to get an image is to include it in your firmware image. This can be done with the file2c utility that ships with the µGFX library. You can then use ROMF to display it. Have a look at the /demos/modules/gdisp/images demo to get started. Also, here's more documentation: https://wiki.ugfx.io/index.php/Images For the future, please make a separate forum topic/thread. This makes it much easier for other people to find answers to similar questions in the future

For now everything seems to work fine :). The font disortion was caused by the DMA2D not working. Now its looking good. However the questions are not over I want to test an image, I've used "lcd-image-converter" to generate a byte array, I've included the header as the first 8 elements like follows: 0x4E, 0x49, (1024 & 0xFF), ((1024 >> 8) & 0xFF), (600 & 0xFF), ((600 >> 8) & 0xFF), (0x2565 & 0xFF) But I struggle to find the correct function to draw it.

Great that you got the new driver working so quickly - nice work! Does everything work properly then? The font looks a bit funky but maybe that's just the font. You can always test with the built-in DejaVu fonts first to confirm that it's working as intended.

Thanks I've did the switch with the results in the attachments, I've also changed the font size to 32 to show the defects better. Additionally gdispGFillArea(g, 0, 0, 1024, 600, Blue) doesnt seem to work. //Update the issues were caused by my DMA2D clocks not being initialized. Afterwards its working as expected.

So, generally the good news is that once you see something on the screen (anything, even if it's distorted), you're generally in good shape. It's usually harder to get to the point where you're no longer staring at a black screen. First of all, I would recommend that you use the current `master` branch of the official µGFX v2 git repository: https://git.ugfx.io/ugfx/ugfx One of the notable changes after the v2.9 release was a rework of the STM32 LTDC driver. You can (and should) read more about the changes here: I think it's wasted effort to debug the issue you're currently having with the old driver. I'd suggest that you get it up and running with the new driver and then we figure out what isn't working for you. Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Hello Joel, Thanks for responding! Im using 2.9 release from the main website. The board in question is an Alieexpress dev board featuring an h743/256Mbit SDRAM and LTDC screen. As for ChibiOS its the current master branch v21 //Update, the following code results in the following #include "ch.h" #include "hal.h" #include "gfx.h" #include "gfx_thread.h" GListener glistener; static gdispImage myImage; static THD_WORKING_AREA(waGUI, 512); static THD_FUNCTION(GUIThread, arg) { (void)arg; gfxInit(); geventListenerInit(&glistener); gwinAttachListener(&glistener); const font_t font = gdispOpenFont("DEJAVUSANS10"); GDisplay * g = gdispGetDisplay(0); while (true) { chThdSleepMilliseconds(200); gdispGClear(g, Black); gdispGFlush(g); gdispGDrawString(g, 20, 20, "Hello from ChibiOS with UGFX", font, Yellow); gdispGFlush(g); chThdSleepMilliseconds(200); gdispGDrawCircle(g, 256, 300, 150, Yellow); gdispGFlush(g); gdispGDrawChar(g, 256, 300, "X", font, Blue); gdispGFlush(g); } } void startGFX(void) { chThdCreateStatic(waGUI, sizeof(waGUI), NORMALPRIO, GUIThread, NULL); }

Hello & Welcome to the µGFX community! Could you please tell us which version of the µGFX library you're using (eg. v2.9 release or the git master branch, ...) and whether you're using a development kit (such as STM32 discovery or similar) or whether you're using custom hardware?

Hello, I'm currently implementing uGFX on a STM32H743iit6 with an 1024x600 screen via LTDC (rgb565). I'm running in some problems where the code from below doesn't render properly. What could be the cause? #include "ch.h" #include "hal.h" #include "gfx.h" #include "gfx_thread.h" GListener glistener; static THD_WORKING_AREA(waGUI, 512); static THD_FUNCTION(GUIThread, arg) { (void)arg; gfxInit(); geventListenerInit(&glistener); gwinAttachListener(&glistener); const font_t font = gdispOpenFont("DEJAVUSANS10"); GDisplay * g = gdispGetDisplay(0); gCoord width, height; width = 512; height = 300; while (true) { chThdSleepMilliseconds(1500); gdispClear(Black); gdispDrawString(10, 10, "Hello, uGFX with ChibiOS!", font, White); chThdSleepMilliseconds(1500); gdispDrawCircle(g, (width, height), 150, Yellow); } } void startGFX(void) { chThdCreateStatic(waGUI, sizeof(waGUI), NORMALPRIO, GUIThread, NULL); } Like seen in the picture the font is disorted and the circle isn't drawn in the center of the screen, however the Y axis seems to be ok?

@Sergey Kushnir I've applied your patch to the feature/gwin_redraw_fix branch (https://git.ugfx.io/uGFX/ugfx/src/branch/feature/gwin_redraw_fix) Would you be able to verify that everything is working as expected before we merge it into the master branch and make a v2.10 release?

Great, Joel! I already had the experience of repairing the operating system PicOS18, after which the forum about this OS just died. The problems disappeared and there was nothing to discuss.

No worries, we'll do it then We mainly asked because this way author information can be incorporated into the git history which is something some contributors care about. I'll try to get this done this week but I need to setup a test case to reproduce the issue and testing your fix first.

Hi, Joel! I can’t be friends with GIT. Maybe someone from your team will do this?

This sounds good - thank you for having investigated this! If you are able/willing to provide a patch (such as git format-patch) we could apply your fix directly to the repository (and have you credited as the author). If possible, adding a comment or two in the source code wouldn't hurt either

See topic The screen is redrawn more than once

As I noted earlier, The _gwinFlushRedraws function contains two branches: "Do loss of visibility first" and "Do the visible windows next". The first branch is for hiding the window. The second branch is for drawing windows with visibility flags set. When a window needs to be hidden, the GWIN_FLG_BGREDRAW flag is set, which is processed in the corresponding branch of the WM_Redraw function. A check is performed, does the window have a parent? If there is a parent, then this parent needs to be redrawed. If there is no parent, then there is nothing to redraw. In my opinion, the logic is as follows. The windows that need to be shown are processed in the second branch of the _gwinFlushRedraws function. Based on this reasoning, I modified the code as follows and marked this places with the label ">>": static void WM_Redraw(GHandle gh) { gU32 flags; >> gU32 parents = 0; flags = gh->flags; gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); #if GWIN_NEED_CONTAINERS redo_redraw: #endif if ((flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) gh->vmt->Redraw(gh); else if ((flags & GWIN_FLG_BGREDRAW)) { // We can't redraw but we want full coverage so just clear the area gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); // Only do an after clear if this is not a parent reveal if (!(flags & GWIN_FLG_PARENTREVEAL) && gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } #if GWIN_NEED_CONTAINERS // If this is container but not a parent reveal, mark any visible children for redraw // We redraw our children here as we have overwritten them in redrawing the parent // as GDISP/GWIN doesn't support complex clipping regions. if ((flags & (GWIN_FLG_CONTAINER|GWIN_FLG_PARENTREVEAL)) == GWIN_FLG_CONTAINER) { // Container redraw is done for(gh = gwinGetFirstChild(gh); gh; gh = gwinGetSibling(gh)) _gwinUpdate(gh); return; } #endif } else { if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done >> parents++; // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); >> #if GWIN_NEED_CONTAINERS >> if (!parents) return; >> #endif // Now loop over all windows looking for overlaps. Redraw them if they overlap the newly exposed area. for(gx = gwinGetNextWindow(0); gx; gx = gwinGetNextWindow(gx)) { if ((gx->flags & GWIN_FLG_SYSVISIBLE) && gx->display == gh->display && gx->x < gh->x+gh->width && gx->y < gh->y+gh->height && gx->x+gx->width >= gh->x && gx->y+gx->height >= gh->y) { if (gx->vmt->Redraw) gx->vmt->Redraw(gx); else // We can't redraw this window but we want full coverage so just clear the area gdispGFillArea(gx->display, gx->x, gx->y, gx->width, gx->height, gx->bgcolor); } } } } } I introduced an additional variable that indicates whether the window has a parent. If there is no parent, then no redrawing occurs. If there is a parent, then it will be redrawed either in this function or later. The gx variable is an auxiliary variable-pointer to an object in the list. Therefore, any setting of flags in this variable is meaningless. I think this code meets your expectations. With this code, redrawing occurs only once.

No, two times.

Hmm. I don't think that is right, and even if it is works it will make the redraw require 2 redraw cycles to work. I think the problem is the bottom gdispGFillArea that is using gx. Whilst WM_Redraw clears any pending drawing operations, the gdispGFillArea doesn't and it should in this case. Try putting back the original code and then changing that bottom gdispGFillArea to... <code> else { gdispGFillArea(gx.... gx->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); } </code> The other area I pointed out is also probably still a bug but that one needs more testing.

I modified the WM_Redraw function code as follows and the double redrawing does not occur. if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; -> }else{ -> gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); -> return; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor());

This code is executed only if the window has a parent. In my case, the container and tabset do not have parents. Therefore, the code is not executed and the code immediately switches to executing first the area clearing, and then searching for windows with visibility flags set and redrawing them. I previously marked this place with the label "3==>".

Hmm. I can see what might be a bug that you can try... <code> gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; </code> As the flags are saved before the redo_redraw label, I think modifying the gh->flags is probably a bug. It should perhaps just read "flags |= ...". Give that change a try and let me know if it helps.

I continued my research. The _gwinFlushRedraws function handles hiding the window in the "Do loss of visibility first" branch. The GWIN_FLG_NEEDREDRAW and GWIN_FLG_SYSVISIBLE flags are checked for all windows. If the GWIN_FLG_SYSVISIBLE flag is set, the window does not require hiding and its redrawing is ignored. I marked this place with the "1==>" label. If redrawing is required, i.e. the GWIN_FLG_NEEDREDRAW flag is set and GWIN_FLG_SYSVISIBLE is cleared, then the GWINwm->vmt->Redraw(gh) function is called. I marked this place with the "2==>" label. void _gwinFlushRedraws(GRedrawMethod how) { GHandle gh; // Do we really need to do anything? if (!RedrawPending) return; // Obtain the drawing lock if (how == REDRAW_WAIT) gfxSemWait(&gwinsem, gDelayForever); else if (how == REDRAW_NOWAIT && !gfxSemWait(&gwinsem, gDelayNone)) // Someone is drawing - They will do the redraw when they are finished return; // Do loss of visibility first while ((RedrawPending & DOREDRAW_INVISIBLES)) { RedrawPending &= ~DOREDRAW_INVISIBLES; // Catch new requests for(gh = gwinGetNextWindow(0); gh; gh = gwinGetNextWindow(gh)) { 1==> if ((gh->flags & (GWIN_FLG_NEEDREDRAW|GWIN_FLG_SYSVISIBLE)) != GWIN_FLG_NEEDREDRAW) continue; // Do the redraw #if GDISP_NEED_CLIP gdispGSetClip(gh->display, gh->x, gh->y, gh->width, gh->height); 2==> _GWINwm->vmt->Redraw(gh); gdispGUnsetClip(gh->display); #else _GWINwm->vmt->Redraw(gh); #endif // Postpone further redraws #if !GWIN_REDRAW_IMMEDIATE && !GWIN_REDRAW_SINGLEOP ... The GWINwm->vmt->Redraw(gh) function also has two branches of rendering. The first branch renders the window if the GWIN_FLG_SYSVISIBLE flag is set. The second branch either does nothing or, if the GWIN_FLG_BGREDRAW flag is set, clears the area and renders windows that have the GWIN_FLG_SYSVISIBLE flag set. This is where the next window is called when the previous one is hidden. I marked this place with the label "3==>". static void WM_Redraw(GHandle gh) { gU32 flags; flags = gh->flags; gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); #if GWIN_NEED_CONTAINERS redo_redraw: #endif if ((flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) gh->vmt->Redraw(gh); else if ((flags & GWIN_FLG_BGREDRAW)) { // We can't redraw but we want full coverage so just clear the area gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); // Only do an after clear if this is not a parent reveal if (!(flags & GWIN_FLG_PARENTREVEAL) && gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } #if GWIN_NEED_CONTAINERS // If this is container but not a parent reveal, mark any visible children for redraw // We redraw our children here as we have overwritten them in redrawing the parent // as GDISP/GWIN doesn't support complex clipping regions. if ((flags & (GWIN_FLG_CONTAINER|GWIN_FLG_PARENTREVEAL)) == GWIN_FLG_CONTAINER) { // Container redraw is done for(gh = gwinGetFirstChild(gh); gh; gh = gwinGetSibling(gh)) _gwinUpdate(gh); return; } #endif } else { if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); // Now loop over all windows looking for overlaps. Redraw them if they overlap the newly exposed area. 3==> for(gx = gwinGetNextWindow(0); gx; gx = gwinGetNextWindow(gx)) { if ((gx->flags & GWIN_FLG_SYSVISIBLE) && gx->display == gh->display && gx->x < gh->x+gh->width && gx->y < gh->y+gh->height && gx->x+gx->width >= gh->x && gx->y+gx->height >= gh->y) { if (gx->vmt->Redraw) gx->vmt->Redraw(gx); else // We can't redraw this window but we want full coverage so just clear the area gdispGFillArea(gx->display, gx->x, gx->y, gx->width, gx->height, gx->bgcolor); } } } } } I believe this is due to the specific implementation of the concept of separating the change of window rendering flags in one operating system thread and the rendering process itself in another thread.

It has been a long time since I looked at the code but... It should be possible to retest the visibility flag in the invisible loop. If the window is now visible don't redraw it because it will get redrawn later.