Joel Bodenmann

Great work! Glad to hear that you managed to get it working! You can use the single-file-inclusion mechanism. Alternatively, some IDEs (and I assume that Code::Blocks is one of those) allows to setup additional directory/file paths for external libraries in the per-project settings. But I never used Code::Blocks so I'm not sure. In general, using the makefile approach is better than the single-file-inclusion approach as two features don't work with the single file stuff as documented in the wiki.

That won't really help much. What you're doing in this case is directly writing into the framebuffer of the display controller. That is as fast as you can get. If you use external RAM yourself then you'll always have to copy it to the actual framebuffer or you have to use a display controller that's on your side (eg. integrated into the microcontroller) such as the LTDC which is featured by some of the F4 and F7 series. But that will not necessarily increase speed. It can be faster in certain cases but the performance gain is minimal and only applies in certain situations. The huge downside is that you get a lot more traffic on your FM(S)C bus because when using something like LTDC you connect the bare display panel to the microcontroller. The LTDC needs to take care of refreshing the display content which means that it needs to loop through the framebuffer in your external memory and send the correct pixel values to the display panel continuously - even if you're not changing the framebuffer contents. Obviously there is a lot more to this than what I've just listed. In general it will be faster, yes. But as you've discovered it's also often more expensive. Unless you have a lot of stuff to write (eg. when keeping log files and stuff like that) you won't get much more out of it. If you worry about performance then external RAM will be a huge improvement as it allows you to store decoded images and implement double-buffering and off-screen rendering.

Hello @PaulB and welcome to the µGFX community! It's correct that the Linux event board file that comes with the library only handles touchscreen events at the moment. However, writing new drivers/board files or extending existing ones is very easy. Currently there's no support for a real visual mouse cursor. That would require a lot of resources as you'd have to either keep an entire copy of the rendered framebuffer or you'd need to figure out which parts need to be repainted which would require partial redrawing of the widgets. These are features that are currently not there because µGFX is meant to work with as little resources as possible. There are plenty of things that we'd like to add but we're currently lacking man-power. Every feature needs to be optional and managing things like this as an optional feature is extremely complex. I'm gonna leave the explanation of the mouse vs. touchscreen stuff to @inmarket. He wrote the original version of GINPUT and I'm not sure of all the details right now - I'd have to digg into it.

@cpu20 can I leave this to you? Regarding the compiler: You'd use the same compiler you use to compile outside of Code::Blocks. Don't forget that Code::Blocks is basically just a text editor on steroids. It doesn't have an integrated compiler or stuff like that. You can set it up to use the compiler you installed in/with cygwin. The same applies to the make utility and all the other stuff. Just point Code::Blocks to the applications in C:\cygwin64\bin.

Hi, Using external FLASH and and LCD on the FSMC bus is possible - I have done it myself plenty of times. The performance of µGFX itself will not be affected at all. You'll just introduce wait states on hardware level when the FSMC is busy accessing the external flash. It's not that easy to tell how much the overall performance will be affected as this depends on a lot of stuff. However, this shouldn't be too much of a problem if you write your application to cope with this. After all, FLASH is usually not accessed all the time. You can use buffers and caching to minimize the amount of transactions to and from the FLASH. I'm not sure how helpful this reply was, sorry.

Hi, As the error tells explains you need to define which underlying system you're using. You do that by setting the corresponding GFX_OS_USE_XXX setting to TRUE in your configuration file. Note that it's a define so you can also just add it in a makefile or anywhere else in the build process. You can find a list of all configuration file parameters here. There's more documentation regarding the port/underlying system here. I hope that helps.

If you need more flexibility in the future you can also write custom rendering functions for the containers. That's described here: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine

Hello Heiko and welcome to the µGFX-Community! First of all I'd also like to thank you for your feedback - we appreciate it a lot! @inmarket basically addressed everything. I'd just like to put more emphasis on the fact that we'd really appreciate it if somebody would start building up an automated testing environment. It's definitely something that's currently absolutely missing but required.

Hello @Maia and welcome to the µGFX-Community! Do you have any specific questions? At the end you really need to handle the animation yourself. You can use the GTIMER module for timers for the animation.

You could also just not use a GIF. BMPs come with extremely little overhead to decode. Of course, more RAM is always better if that is an option

Just as a side note: Keep in mind that the FreeRTOS heap managers use words instead of bytes for the heap sizes.

Did you check for differences in the configuration file gfxconf.h? Make sure that when converting the image yourself you use the file2c flags -dcs as described in the wiki.

The µGFX library v2.8 includes support for the STM32F469i-Discovery board that works out of the box. Please try that.

Glad to hear that everything is working

Hello and welcome to the µGFX community! Did you have a look at the virtual keyboard example that you can find in /demos/modules/gwin/keyboard? I am pretty sure that you're missing this line: // We also want to listen to keyboard events from the virtual keyboard geventAttachSource(&gl, gwinKeyboardGetEventSource(ghKeyboard), GLISTEN_KEYTRANSITIONS|GLISTEN_KEYUP);

Yes, you can run µGFX on that A20 without any problems. µGFX runs on Linux out of the box without any problems. You can either use the SDL or X11 drivers or you can use the driver that directly accesses the linux framebuffer. All of those exist and are working out of the box. The same applies to touchscreen, mouse & keyboard input. There is no existing example for that specific setup but you can have a look at the raspberry-pi example if that helps you: https://wiki.ugfx.io/index.php/Raspberry_Pi

Well.... why don't you just display an image then?

Hi, You can find pre-compiled binaries of the font converter in the /tools directory of the µGFX library. That allows you to run the font converter locally without any restrictions.

That's the µGFX-Studio: We are happy to help with whatever we can. The µGFX developers themselves actually maintain this forum in their spare time. Alternatively, you can purchase a support plan form our website. You usually start off by having a working project for your platform. Once you have everything running, you'll just add the µGFX library to that as you would with any other library. There is a generic documentation that explains how to add the µGFX library to an existing project on the wiki. Additionally, there are many different IDE specific guides out there that you can have a look at. As far as I know, CCS is Eclipse based so the generic Eclipse guide or the IDE specific guides for IDEs that are Eclipse based (eg. ChibiStudio) will help. Along these lines: @cpu20 is the IDE integration specialist of this community We provide µGFX drivers that allow rendering to a QWidget and to retrieve user inputs from that QWidget to the µGFX library. It's basically a driver that makes a QWidget become a virtual display (with touchscreen).

Did you check the return value of the gdispImageCache() function call? An image decoder can refuse to cache the image. An image also won't be cached if there's not enough memory left.

glad to hear that you got it working

You can mix C and C++ without any problems. You just have to make sure that you use the C++ compiler to compile C++ sources and the C compiler to compile C sources. That seems to be the most common mistake. Other than that, you can of course not include C++ code (eg. #include <iostream> or #include <functional>) in code that gets compiled by the C compiler.

You don't need a pixmap in this case. You can simply cache the image using gdispImageCache(). A cached image is stored as a decompressed bitmap just like it would in the pixmap with the simple benefit that in some cases, some really basic RLE will be applied that decreases the image size without having a real impact on the rendering performance. To answer your question anyway: You render to a pixmap like you would to any other display. A pixmap is nothing but a virtual display. You use all the normal GDISP rendering calls. Therefore, you can render an image to a pixmap using the regular gdispGImageDraw() function. The wiki demonstrates rendering to a pixmap: https://wiki.ugfx.io/index.php/Pixmaps

Great! Thank you for sharing that with the community!

You have to enable unicode support in your configuration file. Of course, also make sure that your source file(s) are unicode encoded as well when you hard-code your strings. Furthermore, make sure that the Chinese glyphs are not being filtered-out by the default filter range of the online converter.