Joel Bodenmann

Yes, the container has no idea when the content of the pixmap changed. The pixmap is a glorified array of pixel values. It doesn't generate any events or similar. Just call gwinRedraw() once you want to redraw the container using the modified pixmap.

Yes, that would be the intended use. Simply assign gwinContainerDraw_Image() as the rendering routine for the container and pass gdispPixmapGetMemoryImage() as the image pointer to the custom parameter of the rendering routine. Should work out of the box and provide you with a lot of joy

I am not quite sure whether I understand your current situation so please forgive me if I am giving a misleading answer. If you are using the image rendering routine of the container and you are using a pixmap instead of an image then you don't need an additional window to display the pixmap. If you are using the window for anything else then you obviously need it for that thing but the container doesn't require an additional window to use the image rendering routine (with or without using a pixmap as an image).

Yep, that's correct. All settings in the gfxconf.h file is about what you want. What the driver is capable of is always located in the *_conf.h file in the actual driver directory itself.

Hello and welcome to the community! The font engine requires fonts to be present in addressable memory. Therefore, if you have an external addressable memory you just have to tell your linker (script) to put the converted font into the external memory and you are done, no file system required - The code stays exactly the same, just the address of the font will change. Loading from other external memory sources such as SD-Cards is currently not possible. Adding support for that is a very low priority task for us as even smaller MCUs tend to have more than enough spare ROM to store a few dozen fonts these days. Proper filter ranges and RLE will further reduce the font size. It's better to keep other resources that are easier to outsource in external memory such as images.

I am glad to hear that you finally got to try the pixmaps. They are really capable of vastly improving performance Can you please post the list issue in a separate topic? It seems to be very unrelated to this topic about flickering with the graph widget.

There should be no difference between using EmBitz or Eclipse if both use Makefile and the same compiler. These IDEs are just glorified text-editors, really. It's difficult to track that issue down. Can you post a picture of the display as well as the information about the compiler that you use for each IDE? You get that by executing this: arm-none-eabi-gcc --version

Regarding the warnings of the STM32_LTDC driver... is it possible that you are not using the latest code? The line numbers in your warnings don't match the ones in the actual driver source-code. We have marked the compiler as tested for now as you reported to us that it's working fine besides those warnings. We will try to figure out the correct pragmas to get rid of these.

We just added the missing default values for these macros: https://bitbucket.org/Tectu/ugfx/commits/3d78787b07ce9c2dafe0869dfd54b734181b7dd6 Can you please grab the latest master of the repository and let us know whether these warnings vanished?

Hello and welcome to the community! As inmarket mentioned you don't have to worry about that in terms of uGFX as we internally take care of that. However, that is in fact a problem you can never avoid. It's a basic principle (or problem) of counters and the systick has the same problem. This problem needs to be handled manually: https://stackoverflow.com/questions/3095623/how-to-deal-with-a-wrapping-counter-in-embedded-c STM32 Systick overflow ... An overflowing systick counter was also the reason why the mouse cursor in Windows 95 stopped working after 47.5 days

Not true. Keil works perfectly fine with 3rd party compilers such as GCC: http://www.keil.com/arm/gnu.asp

Whenever possible: Texteditor & make. Whenever required: Keil. Always avoiding: Eclipse. Yeah, that sums it up pretty well I think Personally I used EmBlocks in the past but it became too cumbersome for me. It has great potential but the project lacks the man-power to move forward. The next thing I want to try is this: http://www.rowley.co.uk/arm/

Hello and welcome to the community! Implementing such behavior would require modifications of the GWIN module. There are similar ways to archive this - all of which come with their own up- and downsides. We just had a long discussion about that and came to the conclusion that it will take a lot more thinking to figure out which is the best way to give the user the ability to implement that behavior. Sadly there's also no quick work-around that we could propose as this requires changes in the GWIN module that will affect all widgets and therefore have to be thought through well. That said it will take some time to get this done due to our current workload being quite high. If this is of high importance we'd suggest purchasing a support package to drastically speed up this process. It will give you direct access to our high-priority support ticket system. Did you see that you can use the existing virtual keyboard widget for that and just create a custom layout that only contains numbers and then assign that using gwinKeyboardSetLayout(). You can have a look at the existing layout in /src/gwin/. It's just a matter of filling in a few structs. That way you will still use the underlying, official code. If we ever change anything (eg. fix some bugs or extend the features of the keyboard widget) you can benefit from them too without changing anything!

Did you follow our guide on how to use the ChibiStudio? There's a step-by-step guide that leads you through the process - it starts with downloading the appropriate Java version: http://wiki.ugfx.org/index.php/Using_ChibiStudio And if you don't like to use that very simplified Makefile we provide then follow the exact same guide but use the Makefile supplied by ChibiOS and modify it according to this guide: http://wiki.ugfx.org/index.php/Using_ChibiOS/RT

Note that with headers you don't have to add the actual file but just the path to the directory CONTAINING the file. In case of the file is in the top-level directory you might have to add that path too (simply add . as path, but I am not sure if that's required or not). Otherwise put those files in a directory named config or something like that and add that one to the include path. Also note that those paths should be relative.

Thank you for your contribution! We will have a very close look at that. However, that might take some time as we have to take care of some other business first.

Well we can't really give eclipse support her because it's not an eclipse forum but mostly because we don't use eclipse ourselves either. If using Makefiles make sure that you added the directory where the header file is located to the include directories path.

Yes. Rendering routines just change how a widget looks. The logic (the behavior) of the widget remains unchanged As the documentation states (http://api.ugfx.org/group___progressbar.html -> Renderings) the image is only used for the active area of the progressbar. The inactive area, the borders/edges and the text are still drawn using regular drawing commands and the currently active widget style. For a more sophisticated use of images I'd recommend writing your own custom rendering routine which is explained here: http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine

When a widget that was hidden becomes visible it needs to be redrawn. For this, the GWIN module calls the currently assigned rendering routine of that widget. The container doesn't keep track of the internal state. It has no idea of what happens in its client area. This means that when you draw a pixel in the to the container (which is really discouraged, see below!) it will not know about it and the next time it redraws itself it won't redraw that pixel. As an opposite example: The console widget has an internal buffer that keeps track of the text that's shown. That way it can redraw the text when the window needs to be redrawn. A window doesn't keep state of your drawing operations. It would take tremendous amount of RAM to do that and as every other widget is based upon that window it would not be very suitable for embedded applications. This means that you can draw to the window but as soon as the window gets redrawn by GWIN it will be cleared again and you have to redo the painting. There's one simple and very recommended solution to your problem: Use Pixmaps. That is the most proper way to handle this. You can draw anything into the pixmap as it behaves like a real display. It even gives you access to the direct pixel values if you need to do some wizard magic. You can assign a pixmap as a background to a container using two different ways: Use gwinBlitArea() to dump the content of the pixmap to the container. This means that you will have to manually maintain the redrawing. Use the image rendering routine for the container widget and assign the pixmap image as the used image. That way it will take care of redrawing automatically. Use gdispPixmapGetMemoryImage() for that.

Can you please post a minimum test case that allows us to reproduce the issue (the crash?). Please be sure to include the image that you are trying to use as well. Containers currently don't come with a built-in rendering routine for gradient backgrounds. Custom rendering is the way to go. Note that there are many different reason why uGFX comes with only so little built-in rendering routines. As a user of the µGFX library we really encourage you to write your own. It's usually really easy and straight forward. You can have a look at the button normal/default draw to see how gradients can be implemented using gdispBlendColors(). We are rewriting the corresponding guide that talks about that. We will include multiple examples on how to write different rendering routines (a very simple one and a more complex one): http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine

As you mentioned there is currently no built-in rendering routine for the radio button widget that handles a images. The only reason for that is: We didn't have time to do that yet. It's correct that you can do that yourself by creating your own custom rendering routine. You can follow this guide to learn how to properly write a custom rendering routine (work in progress): http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine Note that you will have to get the latest master of the repository as we fixed a few minor things that prevented the user from putting the custom rendering routine in the applicaton directory (never modify the library source for things like that!).

If you want full control I would recommend you following this very short guide that will explain to you how to modify the ChibiOS makefile to include uGFX: http://wiki.ugfx.org/index.php/Using_ChibiOS/RT That happens when you have GINPUT_TOUCH_USER_CALIBRATION_LOAD set to TRUE in your configuration file without actually supplying the corresponding loading routine for the calibration data. You can find more information about that here: http://wiki.ugfx.org/index.php/Touchscreen_Calibration

Hello harsha and welcome to the community! This issue is explained in the wiki: http://wiki.ugfx.org/index.php/Linux The X11 driver only uses setPixel() and the performance is therefore horribly slow.

I think you are mixing things up: NativeFS from the GFILE module and NativeFormat from the GDISP (image) module have nothing in common. Those are two completely separate things. The NativeFS is just a layer that glues the underlying operating systems file system to GFILE. NativeFS does not use ROMFS for anything. The Native format for the GDISP images is something completely different. It's an image format.

I mentioned another reason for that: Some compilers that our users and customers are using have problems with conditional function pointers. Also, there's more than just the callback function that changes. The init structure and so on is not the same as well. The function would basically be split in half internally. There's not much gain.