Joel Bodenmann

Welcome to the µGFX community & welcome for sharing your workaround, @Matteo Vigni!

Hello & welcome to the µGFX community! The Zephyr port definitely needs a port to v2.9 to cover for the problem you listed (mainly the type updates) and making it therefore future proof for µGFX v3.0. We would greatly appreciate it if you could provide an updated version of the Zephyr port The Zephyr port was provided by the community member @nathan.loretan and I think µGFX 2.7 or 2.8 was the latest release at that point. However, porting to the current v2.9 version should be very easy as not much changed on µGFX's side (see changelogs). The board files are completely independent from the GOS layer. You should be able to use any board file no matter what underlying system you're running µGFX on.

If the memory of the image you're passing is correct then the following two cases seem the most likely: Your GDISP driver / display controller / display module setup has an issue. Perform tests as explained in my previous post to check. There's an issue in the PNG decoder. You can simply test another PNG image to see whether you have the same issue.

Unfortunately nothing comes to mind. Things you can do to proceed: Try to display the same PNG file in an µGFX application you compile as a native desktop application (Windows, Linux, Mac OS...). If that works without any problems there's a good chance that the image you're loading into memory is corrupted at which point you'd need to revisit your USERFS implementation. The PNG decoder is in general known to work although it is not used as often due to large memory requirements for the decompression algorithm. Before all of this it might be worth confirming that your display driver is working correctly. Run some tests (eg. color fills, drawing rectangles, circles & text) to see whether the issue is actually in the image loading/rendering and not somewhere else.

It's a bit difficult to judge based on the image with the angle & blury-ness but it looks like there's an issue in the setup of the display controller scanlines. The ili9341 display controller families are known to have various issues such as mis-matching silicon revisions and suppliers simply shipping a slightly different chip. This usually results in incompatible initialization routines. Check out the GDISP driver file (inside something like /src/drivers/gdisp/ili9341/) and check the initialization routine. Usually the manufacturer and/or supplier of a display module will provide you with minimal sample code. Simply take the initialization routine you get from the sample code and plug it into the GDISP driver. I'd also recommend you to use the forum search - there's plenty of these issues regarding ILIxxxx display controllers around.

Hello & welcome to the µGFX community. Please excuse the inconveniences you experienced. µGFX is very much alive and active. There has simply been an error in the automatic ordering system. All of your orders were received and by now you should have received a manual response to your purchase inquiry. Please do not hesitate to contact us again should you still not have received anything.

I've never heard of anyone writing a µGFX GDISP driver for the NT35510 driver. However, writing a driver is very easy! You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/Display_Driver_Model You can find examples in form of dozens of existing drivers in the µGFX library directory under /drivers/gdisp Furthermore, we're happy to help wherever we can! Just ask if you have any questions.

The imagebox should automatically redraw when necessary. The only thing you have to make sure is that the image remains opened. The imagebox widget will simply clear the area if the assigned image is not opened (i.e. "nothing" will be rendered).

We're happy to help where we can - don't hesitate to ask on the forum. I assume you're referring to the attachment of a few posts above yours? I had no issues downloading it. I've re-attached it to this post. Let me know if the issue persists.ArduinoIDE_ESP32_ILI9341.zip

That should definitely go into a separate topic :)

The µGFX library is actively maintained. There is currently no release date for µGFX v3 as we want to put our best efforts into it. The development repository of v3 is not public hence there's very little publicly visible efforts. µGFX v2.9 is known to be stable. While we do not currently add new features to it we are applying patches & hotfixes as they appear. We can only recommend using the µGFX library in your commercial product ? If it helps: There's an equally named company behind the µGFX library - This is not just a floating piece of software. Also professional support is being handled through this company.

This was fixed in commit ff93884f71f783627f196330fd0c9f6a639bee56.

Hello & welcome to the µGFX community! It would be definitely very appreciated if somebody could update the demo

Hello & welcome to the µGFX community! This is certainly possible. The graph widget demo also plots multiple values in the same graph. However, in this case you'll most likely just end up having more than one graph widget/window on the same "display page".

Hello & welcome to the µGFX community! Thank you for bringing this to our attention. We'll put it on the ToDo list for checking. Could you please leave a short description (and if necessary examples) as to why you think that this is the case? Some screenshots might also be helpful if possible

Feel free to open a thread in the support section of this forum stating what you're trying to accomplish, what you already have (how far you got) and what problem(s) you're facing. "Doesn't even compile" is not enough information for us to help you in any way.

If you're having issues compiling µGFX successfully, you can always open a thread in the support forum where you'll find people that are happy to help where they can. µGFX is being compiled a lot against / for the win32 platform as it is being used a lot as a development environment.

Hello and welcome to the µGFX community. Providing pre-built libraries (either static or dynamic) for µGFX is not a very good idea. The library makes heavy use of compile time optimization based on the various configuration options given in the main configuration file and the driver configuration files. All those compile-time options influence the code that is being presented to the compiler during the pre-processor stage. Therfore, the binary code produced by the compiler (and eventually also the linker) depend on those options. This reason makes it very useless to publish binaries. For certain things such as the GDISP feature set we could just enable everything which would result in a larger binary and call it a day but for many of the other options that's simply not possible because the pre-processor makes changes based on the underlying system, the compiler being used and so on. Furthermore, some options are application specific (eg. GDISP_NEED_MULTITHREAD). TL;DR: Publishing pre-built binaries for uGFX is not a good idea because of lots of pre-processor modifications.

Thank you for bringing this to our attention. We have fixed the problem.

The imagebox widget (in the code the GImageObject structure) contains the gImage member. I didn't try it but you should be able to just open a file regularly and load it into a gImage object (named gdispImage in older versions of the library) and then assign that to the imagebox widget's gImage member. Afterwards you have to trigger a re-render of the imagebox widget. Note that the underlying widget object should always be treated as a blackbox and you should only use the GWIN highlevel API passing GHandle around. If you want this functionality I'd recommend that you implement a proper API call for this in the imagebox widget. Pull requests are of course welcome ?

The clearing operation is currently hard coded in the GDISP driver post-init procedure: https://git.ugfx.io/uGFX/uGFX/src/master/src/gdisp/gdisp.c#L659 It would be rather easy to wrap that call in a macro such as `GDISP_STARTUP_CLEAR` so that it can be controller in the configuration file. Pull requests are welcomed ?

Hello & welcome to the µGFX comunity! The µGFX library has been designed to be completely agnostic. In the 7 years of its existence we never came across a situation (platform, operating system, compiler, architecture, ...) where µGFX didn't run on. The library comes with built-in drivers to run on Linux. The "Linux drivers" support X, SDL or direct kernel framebuffer. You can find more information in the documentation (eg. the wiki & API docs). There is no existing display driver for the ATSAMA5D36. Which driver is the closest to take as a starting point depends on how the display controller works. µGFX supports all possible display driver models (see the driver docs wiki). You can find all existing drivers in the /drivers/gdisp directory. We're happy to help where we can - The more specific questions you ask the further we'll get.

Hi, Currently there's no way to modify the behavior of the default clearing & orientation of the pixmaps. The startup color clearing behavior is implicitly implemented by the fact that a pixmap is just regular GDISP driver like any other "real" / "physical" display. The GDISP driver calls gdispInit() as part of the driver initialization - and therefore also when creating a new pixmap. The orientation is simply hardcoded. You can find the related code here: https://git.ugfx.io/uGFX/uGFX/src/master/src/gdisp/gdisp_pixmap.c#L113

Hello and welcome to the µGFX community! Those fonts (and the two UI fonts) have been custom designed by the µGFX developers. The sources of these fonts are not openly available and therefore there won't be any easy solution for you to modify them. If you're a commercial customer you can contact us via e-mail to further discuss possible solutions.

Just before we dive too much into this: Can you replicate the same issue with the latest version of the µGFX library? The font stuff (especially wrapping and alignment/justification) has been reworked intensively in a release after 2.4 (can't remember, was 2.7 or 2.8 I think - check the changelogs). If you integrated µGFX properly into your project you should be able to just replace the library directory. If upgrading is for some reason not an option, I'd recommend you to first investigate and re-evaluate why that is not an option and if the situation stays the same you can go through the changelogs and git history to figure out which patches were applied to this and cherry-pick those patches to your copy of µGFX 2.4.