Joel Bodenmann

Have a look at the GDISP driver / GDisplay documentation. It tells you the function signature (the function name is gdisp_lld_fill() or something like that, that the linker will try to link against). If you implemented the hardware filling functionality into your driver correctly then it should just work. Maybe you forgot to set the corresponding define in the driver configuration file. You might want to have a look at some of the other drivers that implement hardware acceleration.

Usually you'd want your event loop to run in its own thread so you'd use TIME_INFINITE as the timeout parameter of geventEventWait(). This solves all your problems. Keep in mind that you have to use gfxSleepMilliseconds() instead of HAL_Delay() in any case as pointed out by @inmarket.

No, we definitely don't suggest to change your hardware. Your hardware is fine. The µGFX code is optimized to always use the best possible method to achieve something. In case of clearing the screen it would use the hardware clearing if you implemented that. If you haven't it will use gdispGFillArea(0, 0, gdispGetWidth(), gdispGetHeight()). That function would then use the area filling hardware acceleration (if you implemented that) or fall back to manually clearing the screen by basically doing setPixel() - which is what you're experiencing currently. Hence we suggest you to simply implement the hardware area filling (rectangle drawing) support into your RA8875 and your problem will be gone. The performance of your entire GUI will increase immensely.

Hello @cotsos and welcome to the µGFX community! That is expected behavior. For various reasons (which all boil down to saving resources), GEVENT doesn't internally buffer or queue up events. Each listener provides its own buffer with the size of one event. Therefore, if you're not listening you'll miss it. This is a design choice that was made to vastly simplify code complexity and decrease resource usage because the event system is only used for GUI interactions with a user which are always very slow. You get the press but not the release because the press event fits into the one-event sized buffer. Then the release event happens but it can't be stored anyway. The proper way of doing this is using the second parameter of the geventEventWait() function which is the timeout parameter. In a usual application where the event loop runs in its own thread you'd leave this to TIME_INFINITE. Using a timeout of 0 is definitely a bad approach because you're almost guaranteed to miss the event(s). I hope that helps. By the way: Can you share with us what kind of performance you get out of that STM32F469i-Discovery driver from the other thread? Just the overall user experience, not actual measurements. Is it so slow that you see the image being rendered or is everything blazingly fast?

Do not attempt to change anything internal like that. Those things are not like that just because for no reasons. The mechanisms used by the GWIN module (and anything else in the µGFX library) are a result of years of experience and many complex pieces that fit together nicely. When not having the big picture you don't see all the things that go on in the background, what simplifications have been assumed to save memory and so on. Changing something like this is the wrong approach for fixing symptoms rather than problems and you will end up with many other problems instead. Implement the area filling in your RA8875 driver and you'll get a huge performance boost already. After that, apply other mechanisms that have been discussed in this forum many times. Any changes inside of the core code, even if it's just so little of a change, will have many side effects and will imply many more problems.

http://api.ugfx.io/group___keyboard.html#gab49f100ac33eed532c18ca8529ab1bfb

Are you absolutely sure that you set the range of the font converter correctly to include those umlauts? Did you ensure that you have your file encoded as UTF8 and that that UTF8 support has been enabled in your config file? If you keep having problems after checking those things above, please attach your converted font file as well as your source font file to your next forum post.

No problem. Glad to hear that you manged to get it working

The new position (value) is part of the event that you receive: typedef struct GEventGWinSlider { GEventType type; // The type of this event (GEVENT_GWIN_SLIDER) GHandle gwin; // The slider that is returning results #if GWIN_WIDGET_TAGS WidgetTag tag; // The slider tag #endif int position; uint8_t action; #define GSLIDER_EVENT_SET 4 /* Slider position is set. This is the only event returned by default */ #define GSLIDER_EVENT_CANCEL 3 /* Slider position changing has been cancelled */ #define GSLIDER_EVENT_START 2 /* Slider position has started changing */ #define GSLIDER_EVENT_MOVE 1 /* Slider position has been moved */ } GEventGWinSlider; Have a look at the slider demo, it shows exactly how to do that. Here's a simplified section of that (untested): const char* sAction; GEvent* event; GEventGWinSliderEvent* sliderEvent; event = geventEventWait(&gl, TIME_INFINITE); switch(event->type) { // Handle slider events case GEVENT_GWIN_SLIDER: { // Cast to slider event sliderEvent = (GEventGWinSlider*)event; switch(sliderEvent->action) { case GSLIDER_EVENT_SET: sAction = "SET"; break; case GSLIDER_EVENT_CANCEL: sAction = "CANCEL"; break; case GSLIDER_EVENT_MOVE: sAction = "MOVE"; break; case GSLIDER_EVENT_START: sAction = "START"; break; } printf("Slider position = %d %s\n", sliderEvent->position, sAction); break; } default: break; }

Do the same thing that you're doing now but read the value that comes as part of the event that you receive as @inmarket suggested. Then, everything will work exactly the way you want it without any dirty or complex workarounds.

Yep, there are a couple of users here on the forum who are successfully using µGFX in visual studio projects. I also know of two commercial customers who do that.

Thank you for your feedback. We tested the built-in search feature of doxygen once and it's really bad in our opinion. It doesn't help unless you type in a word that exists exactly like that (eg. the proper function name or similar). Other than that, using Google and restricting the search results to api.ugfx.io is the proper & most helpful way.

Assuming that you're using the built-in image button rendering function of the button widget you just pass a different gdispImage* pointer via the custom parameter to the rendering function. The button widget doesn't store the pointer to your image at all, it just takes the custom parameter of the rendering function and casts it to (gdispImage*) that's all. Therefore, changing the image works like this: gwinSetCustomDraw(ghMyButton, gwinButtonDraw_Image, &myNewImage); With the images of the list box widget it's a different story because the image is actually being stored as part of the list item object. Changing the image is simply a matter of using the corresponding high-level API that has been added exactly for this: gwinListItemSetImage(ghMyImage, 0, &myNewListItemImage);

Actually, thinking about this, the proper solution is to create a custom gdisp_lld_control() command implementation that allows re-calling the driver initialization through gdispControl(). You can have a look at other existing drivers that use custom control commands such as the SSD1306 and the AlteraFramereader drivers.

Well, the proper solution is to add proper shielding and taking other measures required to pass the EMC test without the device becoming unusable Yes, gfxDeinit() will call the deinit() function of all modules, sub-modules and similar. It's the same thing as gfxInit() but in reverse. It can only clean-up the mess it created itself, so all the objects you allocated memory for yourself are not managed and you have to take care of those manually (you need an application wide deinit()). Deinitialization is not very well tested because it's not really needed in situations where µGFX is being used in the first place. The need for deinitialization usually shows a bad design (again, not in general but in systems where µGFX is being used in the first place). You can manually re-call the initialization function of the display driver but that's not supported from our side and vastly discouraged.

We implemented the palette support for BMP as part of a commercial product development (paid support). Initially the project called for both BMP and GIF support but at the end everything was realized with just BMP images so there's nothing done on GIF so far and there's nothing on the schedule / ToDo list for that. As we're currently building a huge pile of things we have to do here on the forum I wouldn't expect anything like that to happen any time soon. But please don't hesitate to contact us if you want us to get it done ASAP as part of paid support.

Hi, Can you please explain your question a bit? What do you mean by "monitor data"?

We had no time to dive into this yet, I'm afraid. I can't promise that we'll find time for that this week. If this is of importance due to a deadline of a commercial project or something like that please contact us if you want to get priority support (paid support).

When making a hard-reset of the display controller you have to re-initialize display controller which means that the internal initialization and post-initialization functions of the GDISP module need to be called (as well as the board_init()). This can only be done by calling gfxInit(). Therefore, you'd have to call gfxDeinit() first and then gfxInit() again. There's no way of buffering the existing GUI in between those operations. This doesn't make much sense in general (none at all). Can you please explain your use case or why you think that you need that so we can try to help you finding the proper solution? This sounds like a very bad design.

One solution is to render the image into a pixmap and then access and modify the pixel data through high-level API that is actually available for that. But that would obviously require you to have enough memory to create a pixmap of the required size.

Hi, What information would you like to get? There were a few different things mentioned in this topic. Please don't hesitate to ask specific questions.

font_t myFont; ... gdispGetFontMetric(myFont, fontHeight);

Hi, The built-in rendering function of the text edit doesn't offer that, no. But you can simply create your own custom rendering function that does that. Basically you can just copy the existing one and modify the justification parameter. Theoretically, you could create a custom rendering function that takes the justification via the parameter. The existing label drawing function does that too.

Yes indeed. Otherwise it's just not a wrapper. A C++ wrapper wouldn't do anything other than calling the equivalent C functions.

Note that you can actually use the GINPUT module without the need of having a touchscreen.