All Activity

Hello, I am experiencing an anomaly involving containers and I wanted to understand if it is an intentional thing or it happens due to my settings/programming. I have a menu cotainer declared as follow: void createWidgetsMenuTST(GDisplay* _display1) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 800; wi.g.height = 480; wi.g.y = 0; wi.g.x = 0; wi.customStyle = &MyCustomStyleContainerTST; ghContainerTST = gwinGContainerCreate(_display1 , 0,&wi,0); I have a second container that contains buttons, like it was a keyboard and I want to make the keyboard and all the buttons in it disappear/appear. To do this I use the gwinHide and gwinShow methods void createWidgetsKeyboard(GDisplay* _displayToUse) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 799; wi.g.height = 279; wi.g.y = 200; wi.g.x = 0; wi.g.parent = ghContainerTST; wi.customStyle = 0; wi.customDraw = ContainerCustomDrawKeyboard; ghContainerNumericKeyboard = gwinGContainerCreate(_displayToUse , 0,&wi,0); gwinWidgetClearInit(&wi); wi.g.show = TRUE; wi.g.width = 124; wi.g.height = 124; wi.g.y = 11; wi.g.x = 15; wi.text = "1"; wi.g.parent = ghContainerNumericKeyboard; wi.customParam = 1; wi.customDraw = gwinButtonKeyboardDraw_Rounded; ghButtonKey[0] = gwinButtonCreate(NULL, &wi); gwinWidgetClearInit(&wi); What happens to me is that when I call the gwinHide functions and specify ghContainerNumericKeyboard as parameter i get that also the main container (ghContainerTST) is alswo redraw. I think the problem is in function void WM_Redraw(GHandle gh) inside "gwin_wm.c" In particular i think that the redraw is done by gdispGFillArea function called on the "else" statement. I don't quite understand if it is avoidable this thing of redrawing containers of containers for example by editing the configuration file or if there are other ways to avoid it 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. 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); } } } } }

Definitely on the ToDo list to check this out. Have to get the v2.10 release out first tho (pretty much done at this point).

Thank-you.

Updated patch! (I found and fixed a cornercase glitch when kerning right-justified text) FlickerlessFillstring_2.patch

Firstly: It was impossible for the font rendering to use the public functions gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop(), because of the mutex. So the patch make these three functions private with new names: StreamStart(), StreamColor(), StreamStop(), with public APIs gdispGStreamStart(), gdispGStreamColor(), gdispGStreamStop() handling the mutex and calling the private functions. And now to answer your question: The patch provides an option GDISP_FLICKERLESS_FILLSTRING. Turn it off, and everything is as before. Turn it on, then yes font rendering with fill will use StreamStart(), StreamColor(), StreamStop(). You may very well decide to remove the option GDISP_FLICKERLESS_FILLSTRING, and just turn the change on permanently. I just felt it was practical to have it as an option for testing purposes. Makes it easy to switch back and forth. The patch does NOT add a count parameter. That would be a driver compatibility breaking change. I just suggest that you add a count parameter in UGFX 3.0. It is an easy change with obvious advantages, given that gdisp_lld_write_color() and gdispGStreamColor() are currently called in loops in many places in UGFX.

Does that mean your patch changes font rendering (the actual painting) to use gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop()? And then on top of that giving gdispGStreamColor() an additional "count" parameter? Apologies if I'm way off here - totally buried at the moment.

There is nothing driver-specific in the patch AFAIK. Performance should be good on any driver, since it uses the generic streaming functions in gdisp which are already optimized for many types of drivers. But of course, I don't have access to every type of display driver for testing.

We had a short internal discussion about this. We'll gladly have a look at your patch but we'll need a bit more time as we're quite busy at the moment. In general, we're quite keen on this additional/improvement if it is not restrictive to a particular type of driver.

The macros using set_rd and clr_rd are macros for a reason. Those pins may be used within a gdisp hardware abstraction layer file to implement the GDISP reading functionality. If your driver or your hardware implementation does not support reading then those macros are unnecessary and, like the uftf library does, you can tie the physical pin up. With regard to the palSetPad and palClearPad, this refers to the LOGICAL level, not necessarily the physical voltage. Depending on your hardware it may be using negative or open collector logic which would give you the effect you see. Note: there are also some user contributed drivers that actually do get this the wrong way around. I am not sure without digging if the SSD1963 driver is one of those.

Not sure I see why the responsibility of bounding can't remain at the higher layer when a count argument is added?

Thank's for your reply! This solution is work perfectly!

Yes this is something that is part of uGFX v3. It is also not quite that simple for all types of displays. You might be working with a display that uses a window based driver, but there are also framebuffer drivers, and other strange types of drivers (like window drivers with positioning, dma etc). There is actually a lot of complexity in just adding that count relating to bounding. At the moment those questions are relatively simple as the calcs are done at the higher layer. When you add the count some of that bounding needs to be moved down a layer, adding to the complexity. This is why this task is in v3. It is at least a major version number update to add that stuff (along with other stuff we wanted in v3).

There are gwin calls that can resize a widget. Try starting there. I am thinking something like: 1. Change the size of the table when you display the console. 2. Change the size back when you hide the console. How you handle this will really depend on what you are doing with your console window and table widget.

#if GDISP_NEED_CLIP gdispGSetClip(gw->g.display, gw->g.x +gw->g.width -4, gw->g.y +offset +1, bar_width, bar_height); #endif

Thank you for the answer, inmarket! I know and understand that uGFX is a very simple graphics library. Therefore, I try to look for solutions similar to those you described in point 1. But sometimes there are situations that cannot be avoided. I just need to understand how to crop the widget display with minimal actions. For example, as shown in the photo, the upper window overlaps the right side of the table. Accordingly, it is possible to reconfigure the constraints for displaying the table. How can this be done with the existing library tools? Will this require making changes to the widget? I assume the following actions. The table is drawn. After some time, a window is called that should be drawn above the table and overlap it. New constraint coordinates are passed to the table object. The table is drawn with these constraints. After some time, the window is closed. Data with the constraints that were there before are passed to the table object. The table is drawn with these constraints. That's all. This is a case in which everything is done manually, but it suits me quite well, since such cases will be very rare. I rely on the fact that widgets call setclip(...) when drawing.

A semi-related observation: StreamColor() / gdisp_lld_write_color() are called for every single pixel when streaming. Often in a loop like this: for(; area; area--) gdisp_lld_write_color(g); When streaming fonts, these functions are called tens of thousands of times. It would improve efficiency is these functions had a "count" argument instead. It would also be easier to map that to hardware level DMA transfers. Also, with a count argument, there would no longer be any need for streaming display drivers to implement gdisp_lld_fill_area(), since gdisp_lld_write_color(g, count) would be equally efficient. Simplifying the drivers a bit. Perhaps something to consider for version 3.0 of ugfx?

uGFX has a VERY simple window manager. It does not currently support overlapping Windows like you are using, as the generic case for that requires some very complex and processor intensive clipping algorithms. It is also an "unbounded" problem in that it may require additional memory allocation that cannot be pre-computed statically. Once the V3 uGFX has been released we can re-examine this as V3 puts significantly better clipping into the GDISP layer. Until then you can either: 1. remove the overlap e.g by reducing the table size while the console is open, or 2. try to detect the situations it is happening and add additional clipping calls to GDISP. The 2nd strategy may not work for you depending on how you are using GWIN so the most promising strategy is probably number 1.

Thank-you very much. We will review and get it integrated asap.

I have tried several different ways of doing this, and found that the attached patch is the best solution. It supports anti-aliasing, kerning, and bwfonts. It implements glyph-by-glyph streaming, which both avoids the flicker, and noticeably improves performance. The only state I have added are the streaming window coordinates and the cursor position. I use the gdisp generic streaming functions, to take full advantage of the accelerations available also for non-streaming displays. gdispFillString() previously took 47ms to draw "Hello World" in a 32pt aa font. This is now down to 35ms. So, about 25% faster. Glyph-by-glyph streaming is incompatible with kerning, so the patch implements line-by-line glyph streaming when kerning is enabled. "Hello World" with kerning previously took 55ms, and is now down to 42ms. Wordwrap is the only feature which is not supported (yet). gdispGFillStringBox() will fallback to the original implementation if GDISP_NEED_TEXT_WORDWRAP is enabled. I have tested this on a ST7789 streaming display with SPI bus. To see the difference in screen refresh flicker, just run this code: while(1) gdispFillString(0, 50, "Hello World", font, GFX_WHITE, GFX_BLACK ); FlickerlessFillstring.patch

I have encountered such a problem. A table is displayed on the screen, in which a row is updated. On command from the button, a frame window with a console is displayed, which overlaps the table. However, the updated part of the table overlaps the window with the console and spoils the view. How to solve this problem? Photos shows this problem.

We did look briefly at doing this a few years ago. The difficulty is getting it to work reliably in all situations e.g. with kerning, antialising etc, and with all fonts. The amount of state required was also significant as well as a number of pre-calculations. Given the amount of work to do it properly to work in all circumstances, and at the time we were thinking if we would replace the font engine with a vector based font engine, we decided it wasn't worth the effort. There was plenty of other work that was higher priority. (At the time we were working on the window manager). If you would like to do the work to do this we would certainly appreciate the patches. It is important however that it works with all fonts and font features (such as kerning and antialiasing), and doesn't overrun the specified area by even a single pixel.

This project was created in 2006 for BelAZ. A competition was organized, and we won among 4 participants. The first version was developed in 1 year. This is an industrial application in serial production. Now, of course, the following versions are used, but the interface design developed by me remains approximately the same. You can find a lot on YouTube. The circuit uses the Atmel AT91SAM7A3 controller, 128 KB flash and 96 KB RAM. The software uses FreeRTOS version 3 with a C++ wrapper. GUI is a deeply reworked someone's library. The entire software took about 60 KB, and graphic primitives and fonts - about 40 KB. Display control via a 16-bit bus. 24-bit address and 16-bit data. Thanks to the use of the built-in graphics accelerator and software tricks, it was possible to raise the fps to 100. I learned a lot from this project.

Pixmaps and global double buffering both consume a lot of RAM.. True, I suppose the performance will depend on the type of display controller. At least for streaming SPI displays it should be more efficient to stream filled glyphs, than to first do a fillarea() and then plot the glyphs pixel by pixel. I'll see if I can put together a patch proposal. It might take me a week or two. Perhaps a patch without kerning support would suffice as an initial proof-of-concept?

Woah - that is awesome - good work! Is this the default dashboard for all BELAZ trucks or is this a retrofit that you're offering? If you like you can "showcase" your project in the "User Projects" section of this forum. That is always appreciated: https://community.ugfx.io/forum/6-user-projects/

Hi, Joel! I'm not a magician, I'm just learning. :). This is my software - BELAZ dashboard. 2006.