Joel Bodenmann

Nope, the hardware acceleration is part of the driver and therfore controlled in the drivers configuration file (/drivers/gdisp/STM32LTDC/gdisp_lld_config.h in your case). You can see that DMA2D is already enabled by default. The gfxconf.h configuration file only controls application stuff. ~ Tectu

Once again: The demo that comes with the uGFX library is supposed to run with the plain, standard ChibiOS/RT that you can download. No special versions, no community stuff, just the plain ChibiOS/RT. I just took the time to verify whether everything still works and indeed the supplied demo worked out of the box without any problems. I uploaded a ZIP to the uGFX homepage that you can download. The demo contains everything you need (including uGFX and ChibiOS). Just download, unzip and execute 'make' and everything should work out of the box. Note that ChibiOS 16 is just a bundle that contains ChibiOS/RT, ChibiOS/NIL and ChibiOS/HAL. Therefore, you should be able to run the exact same demo without any modifications by just swapping the ChibiOS directory (and modifying the path in the Makefile if the directory hierarchy changed). Please give the project that you can download here a try and let us know if it worked. ~ Tectu

I just realize that this board file can be found in the uGFX directory. I have no idea who put it there. But that board file is definitely NOT a good example. We'll either clean it up get rid of it. Sorry for the inconvenience! As an example on how to talk to a display controller via SPI using ChibiOS/HAL you might want to look at this: /boards/addon/gdisp/board_SSD1306_spi.h ~ Tectu

Hello Dolence and welcome to the community! There are many things that can go wrong here so let's go through a short list: Make sure that your SPI pins are initialized properly. It's a good manner to initialize ALL pins in the board_init() function. So do the same as you did for the Reset, CS and DS pins for the MOSI, MISO and SCK pins. Use the ChibiOS/HAL API for handling the SPI. Currently you are manually accessing some of the SPI registers which is NOT recommended when working with ChibiOS. You can find plenty of examples on how to use the ChibiOS/HAL API to interface an SPI client in the various ChibiOS examples, demos and testhal as well as for some other displays and touchscreens in the uGFX boards directory. Make sure that you use spiSelect() as well as spiUnselect() inside the acquire_bus() and release_bus() functions. Use the synchronous API (spiSend() if I remember correctly) to send the actual data. Check your SPI modes. Make sure that the clock polarity etc. is set properly. Your ChibiOS/HAL SPI config struct seems a bit odd. Usually the ILI9341 should work with all default settings. Just limit the clock speed but don't touch the SSE, SSI and so on (I might be wrong here). Check the SPI signals with an oscilloscope or a logic analyzer. Lastly: We have had multiple issues with the ILI93xx drivers where a supplier claimed that it's one display but in fact it was another one. While commonly this usually happens with the ILI9325 vs. ILI9320 we have seen the same with the ILI9341. If none of the above fixed your issue I'd recommend trying all the other ILI93xx drivers. This should be very straight forward as the board files for all those drivers are exactly the same. I hope that helps to resolve your issue. ~ Tectu

That's nice! Can you upload your project so everybody can benefit? At the end we want heavily extend the 'ready-to-use' projects that can be downloaded from the uGFX homepage. Just to clarify: Did you get this working based on the project I posted a couple of posts earlier? ~ Tectu

Very interesting. I guess we have some reading ahead of us I guess that this will depend a lot on the used memory (speed) and the used resolution. Anyway, my statement "Adding su pport for the second layer is fairly easy" was from the actual implementation point of view. uGFX already implements everything required to handle a second layer. The required changes only have to happen in the STM32LTDC driver. But let's not get too off-topic in MobileWill's thread. We can always open a new discussion thread in the Development section ~ Tectu

This is a bit a problem with the STM32F429i-Discovery board: The people who designed this board decided to use a display that has an internal controller (ILI9341). The entire purpose of having the LTDC (and DMA2D) peripherals is that you can directly hook up the bare display panel without any dedicated controller in between. The ILI9341 can do this but it needs to be put into this mode first. This is a configuration step that happens through the SPI interface. So when uGFX is initializing the driver, it will first tell the ILI9341 display driver via SPI that it should stop bothering and just directly route the RGB interface through. This is why the board file of the STM32F429i-Discovery is so cluttered and full of stuff. You can compare it to other board files. Usually its just a matter of a couple of lines of code. I have no idea what the issue with SPI5 would be. Maybe ChibiOS/HAL changed something. As mentioned I currently can't give it a try as I am on the road and most likely I won't find time for this before next week. All I can tell you is that the Makefile based example projects that can be found in the STM32F429i-Discovery board directory were known to work very well. Very happy to hear that We are indeed very keen to make uGFX become the best embedded GUI library available while keeping the sources open and maintaining an active community. Actually those where some of the main reasons why I started uGFX. DMA2D is supported by uGFX. If you have a look at the STM32LTDC driver you can see that the driver config has a corresponding define for that to enable or disable DMA2D. The performance gains are HUGE! As of now you can't use the second LTDC layer, that is correct, but the DMA2D hardware acceleration works on one layer. Adding support for the second layer is fairly easy and it's on our ToDo list, just currently not that high important. What basically needs to be done is initializing the second layer. Then, use a gdispControl() command to return a GDisplay* pointer of the second layer and you're done. Now you have two separate displays you can talk to. Once can then proceed by adding more API to switch the currently active layer and so on. ~ Tectu

Hello MobileWill and welcome to the community! king2 has already answered most of your questions so I'm just being a bit more specific here: 1. The /boards directory doesn't contain any drivers. It only contains what we call board files. The board files contain functions which uGFX uses to communicate with your hardware. For example, there can be a function to write a byte, another to read a byte and another function to change the intensity of the backlight. These are things that we can't do for you because it heavily depends on the user hardware. The board files are a very flexible way of providing the user with the possibility to run the same software on any platform. So in you case, if you have a look at /boards/base/STM32F429i-Discovery you will see that it doesn't contain a single line of actual uGFX code. The code in there is mostly 3rd party code to work with the RAM and so on. The board.mk Makefile includes the actual drivers which are located in /drivers. 2. The last time we checked the examples for ChibiOS/RT 2.6 and ChibiOS/RT 3.x that are located in the board directory of the STM32F429i-Discovery board worked out of the box. ChibiOS 16 just seems to be a new way to give the entire bundle (HAL, OS, ...) a version number so you are still using ChibiOS/RT 3.x and therefore the examples should work. Sadly we can't test that right now. 3. Regarding your question about the window stuff: uGFX comes with a full window manager. We also provide widgets to create dialog boxes and so on. Furthermore, it's possible to completely modify how a widget looks from the actual user space application code. This means that you can change the default look of our slider widget without modifying the actual uGFX library code. Most widgets also come with a built-in rendering function that can handle images in case of you have some more advanced needs. It is also possible (and comparably quite easy) to write your own widgets. You can read more about this stuff in the following locations: http://wiki.ugfx.org/index.php/GWIN http://wiki.ugfx.org/index.php/Widgets http://wiki.ugfx.org/index.php/Creating ... ng_routine You might also want to talk to king2 about that as he recently worked a lot with modifying how widgets look 4. Any display panel will work with the hardware acceleration provided by the STM32F429 microcontroller as long as you can hook it up to the LTDC interface. This means that in general any panel with an RGB interface will work. I hope that helps a bit. Please do not hesitate to ask any further questions. And let us know when you had any issues getting the examples for ChibiOS that are located in the board directory for the STM32F429i-Discovery working. ~ Tectu

Hello CShark and welcome to the community! When I understand you correctly you managed to make the LED blinking with the project I attached in my last post? The errors you get is because uGFX isn't available/linked properly. I just took a look and it seems like I have removed the uGFX part from the Makefile. What you need to do in the Makefile is the following: Set the GFXLIB variable to the path pointing to the µGFX library root directory Include the main µGFX Makefile (/ugfx/gfx.mk) Add GFXSRC to the sources variable/list Add GFXINC to the include paths variable/list Include additional Makefiles of the µGFX library to include board files, drivers, ... That would look something like that (I haven't tested it! I'm currently on the road): ################################################################################ # Generic Makefile for STM32 based applications using StdPeriph/STM32Cube. # # # # Copyright (C) 2015 by Joel Bodenmann # # # # Feel free to use this makefile without any warranty on your own risk. # ################################################################################ # This is the name of the binaries that will be generated TARGET = project # Some paths CMSIS = CMSIS HAL = STM32F7xx_HAL_Driver # Include uGFX stuff, don't forget about $(GFXSRC) and $(GFXINC) further below GFXLIB = /path/to/your/ugfx/directory include $(GFXLIB)/gfx.mk include $(GFXLIB)/boards/base/STM32F746-Discovery/board.mk # Here we add all *.c files that we want to compile CSRCS = \ $(GFXSRC) \ $(HAL)/Src/stm32f7xx_hal.c \ $(HAL)/Src/stm32f7xx_hal_cortex.c \ $(HAL)/Src/stm32f7xx_hal_flash.c \ $(HAL)/Src/stm32f7xx_hal_flash_ex.c \ $(HAL)/Src/stm32f7xx_hal_rcc.c \ $(HAL)/Src/stm32f7xx_hal_rcc_ex.h \ $(HAL)/Src/stm32f7xx_hal_gpio.c \ $(HAL)/Src/stm32f7xx_hal_dma.c \ $(HAL)/Src/stm32f7xx_hal_i2c.c \ $(HAL)/Src/stm32f7xx_hal_ltdc.c \ $(HAL)/Src/stm32f7xx_hal_pwr.c \ $(HAL)/Src/stm32f7xx_hal_pwr_ex.h \ system_stm32f7xx.c \ main.c # Here we add all *.cpp files that we want to compile CPPSRCS = # Here we add all *.s files that we want to compile (Don't include startup file) ASSRCS = # Here we add the paths to all include directories INCS = \ $(GFXINC) \ $(CMSIS)/Device/ST/STM32F7xx/Include \ $(CMSIS)/Include \ $(HAL)/Inc \ . # here we add the paths to all custom libraries LIBDIRS = # here we add libraries LIBS = # StartUp file STARTUP = startup_stm32f746xx.s # Linker script LDSCRIPT = stm32f746nghx_flash.ld # The controller type CONTROLLER = STM32F746xx # MCU flags MCUFLAGS = -mthumb -mcpu=cortex-m7 # Should a map file be generated? (yes / no) GENERATE_MAP = no # The following variables hold binaries and settings ARCH = arm-none-eabi AS = $(ARCH)-gcc LD = $(ARCH)-gcc CC = $(ARCH)-gcc CPPC = $(ARCH)-g++ SIZE = $(ARCH)-size OBJCOPY = $(ARCH)-objcopy ASFLAGS = -ggdb -Wall CFLAGS = -ggdb -Wall -std=c99 CPPFLAGS = -ggdb -Wall LDFLAGS = -lnosys -fno-exceptions -fdata-sections ################################################################################ # Don't change anything below this line # ################################################################################ # Some directory and file magic BUILDDIR = build OBJDIR = $(BUILDDIR)/obj MAPFILE = $(BUILDDIR)/$(TARGET).map # Add the startup file ASSRCS += $(STARTUP) # Generate the object names OBJS = $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(CSRCS:%.c=%.o)))) OBJS += $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(ASSRCS:%.s=%.o)))) OBJS += $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(CPPSRCS:%.cpp=%.o)))) # Automate the inclusion paths CFLAGS += $(INCS:%=-I%) $(MCUFLAGS) -D$(CONTROLLER) -DUSE_STDPERIPH_DRIVER CPPFLAGS += $(INCS:%=-I%) LDFLAGS += $(LIBDIRS:%=-L%) $(INCS:%=-I%) $(LIBS) $(MCUFLAGS) -T$(LDSCRIPT) # Some user settings magic ifeq ($(GENERATE_MAP), yes) LDFLAGS += -Wl,-Map=$(MAPFILE),--cref endif # This is the default target if the user does just calls 'make' all: build size # Build all the files build: builddirs $(BUILDDIR)/$(TARGET).elf $(BUILDDIR)/$(TARGET).bin $(BUILDDIR)/$(TARGET).hex # Create the required directories (if not already existing) builddirs: @mkdir -p $(BUILDDIR) @mkdir -p $(OBJDIR) # Create the *.bin $(BUILDDIR)/%.bin: $(BUILDDIR)/$(TARGET).elf @$(OBJCOPY) -O binary $< $@ # Create the *.hex $(BUILDDIR)/%.hex: $(BUILDDIR)/$(TARGET).elf @$(OBJCOPY) -O ihex $< $@ # Link everything together to a *.elf file $(BUILDDIR)/$(TARGET).elf: $(OBJS) @echo Linking $@ @$(LD) $(LDFLAGS) -o $(BUILDDIR)/$(TARGET).elf $(OBJS) # Compile assembly files $(OBJDIR)/%.o: %.s @mkdir -p $(dir $@) @echo Compiling $^ @$(AS) $(ASFLAGS) -c -o $@ $^ # Compile c files $(OBJDIR)/%.o: %.c @mkdir -p $(dir $@) @echo Compiling $^ @$(CC) $(CFLAGS) -c -o $@ $^ # Compile cpp files $(OBJDIR)/%.o: %.cpp @mkdir -p $(dir $@) @echo Compiling $^ @$(CPPC) $(CPPFLAGS) -c -o $@ $^ # Print size information size: $(BUILDDIR)/$(TARGET).elf @echo @echo $(SIZE) $^ @echo $(FOO) # Clean up clean: @rm -rf *.o $(BUILDDIR) $(OBJS) $($MAPFILE) $(TARGET).* @echo Done # Clean must be a phony target so make knows this never exists as a file .PHONY: clean ~ Tectu

Oh dear, I completely forgot about this one! Sorry! I got disturbed while working on the new STM32F746-Discovery baremetal project and then forgot about it. Sadly I won't have time to finish this in the next 10 days. However, I already have a project that compiles correctly, it just currently doesn't show anything on the screen. If anybody wants to have an early look I attached the project to this post. The new project uses a new dedicated Makefile and the latest STM32F7Cube HAL. Edit: I just had a look. There must be an issue in the initialization code as the LED doesn't start flashing. Compiling with uGFX works just fine, tho. If nobody will have fixed this I'll finish this next week. ~ Tectu

Hello Sillvers, pleased to meet you again too That sounds like you're assigning the new image the wrong way. What you need to do is calling gwinSetCustomDraw() with the new image as the custom parameter. Like this: gwinSetCustomDraw(ghProgressbar1, gwinProgressbarDraw_Image, (void*)&newGdispImage); That will automatically update everything that needs to be updated and issue a redraw. Note that you might want to close the previous image to free some resources (depending on your needs). As inmarket mentioned you NEVER EVER have to manually call a rendering routine. The GWIN module takes care of redrawing when something needs to be redrawn. If you need to issue a redraw manually, use gwinRedraw() instead. That will use the currently assigned rendering routine to redraw the widget. ~ Tectu

Hello Sillvers! Is it possible for you to provide us with a minimum working example (main.c, gfxconf.h, the actual original image and the converted image) so we can easily try this ourselves? That would save us a heap of time setting up a new project Note that you can easily upload a .ZIP archive to your post. ~ Tectu

Happy to help! ~ Tectu

Assuming that you are using the existing image rendering routine for the button widget you just have to change the image that's being passed through the custom parameter. You do that by calling gwinSetCustomDraw() again and just using a different parameter. Note that as you only change a pointer the GWIN module doesn't know that it has to redraw the button widget. Therefore you have to issue a redraw manually using gwinRedraw() after you modified the image pointer. Keep in mind that the image passed to the rendering function must be opened already. You might also want to close the previous image - depending on your needs. Important note: When you just want to show a different image for when the button is released and when the button is pressed to make a visual "Click" effect then that has already been done for you! The existing image rendering function for the button widget can take an image that's either one, two or three times the height of the actual button. This way you can stack the image for the 'released', the 'pressed', (and optionally the 'disabled') state on top of each other and use that as one image. The button widget will automatically render the correct one depending on its current state. You can find more information about this in the API documentation and by using the forum search. This is also already supported by the uGFX-Studio. If you select the image rendering function on a button then you can not only submit the image path but also specify how many images you have (1, 2 or 3). ~ Tectu

If the currently existing label widget does everything for you and you only want to make it look different then the right way to implement a label with a transparent background is to write a custom drawing routine which is explained in this article (please do not hesitate to ask if something in that article is unclear). Inside that drawing routine you'd use gdispGDrawStringBox() instead of gdispGFillStringBox(). Note that you can dynamically change the used rendering routine during runtime by using gwinSetCustomDraw(). You can pass built-in rendering functions to that function too. Otherwise, depending on your needs, you can write a custom rendering function that conditionally clears the background or not. You can use the custom parameter for this. The nice thing about a void* is that you can either just pass a boolean or an entire configuration struct should you have more complex needs and still want to avoid writing a custom widget. If by user you mean the person that uses the uGFX library (the developer of the firmware) then he has to know whether he wants to use a transparent label or not. It depends on the application. As mentioned in another thread using transparent labels doesn't make a lot of sense because when the label text changes you are forced to clear the area somehow. If it's not done inside of the label rendering routine you'll have to do it externally by refreshing whatever is below the label which kinda breaks the purpose of having a window manager in the first place. In my opinion having the need for a label with transparent background is a strong indication that you'd want to write a custom widget instead. It again depends on your needs. If you for example want a label with a transparent background because you want to make a button with an image then use the existing image rendering routine of the existing button widget instead. It will draw the image and then the text on top of it so it behaves like it's a label with transparent background. If you have more specific needs write your own widget where you render the text on top of whatever it is by using one of the GDISP text drawing functions that doesn't fill the background. One of the limitations of the GWIN module is that each widget must be able to clear it's own background. This is a limitation we decided to have in order to keep the resource requirements as low as possible. So far the only exception we made is with the container where we supply a transparent rendering function because containers can be used to just logically group other widgets. I'm afraid I am not sure whether I understand what you mean. If you want to be able to conditionally clear or not clear the background of a label then using a custom rendering function and using the custom parameter for this as explained above is the right way to go. If you have more complex needs you could add your own color format that supports transparency (eg. ARGB). That however will be more work than just writing your own widget (again, depends on what you want to archive). Two main reasons for that: 1) We feel that the two functions behave very differently and distinguishing them is easier by just looking at the function name rather than searching for some parameter hidden in the already very long list of parameters. Also, that parameter would either be a boolean value which would make it very hard to guess what the function really does for somebody who's reading the code or it could be a flag which would be harder to remember. 2) We found that some compilers are having serious issues with passing function pointers conditionally which would be requires when using one function and just enabling/disabling the background filling by a function parameter. It's possible that there are other reasons why we settled this way. The code was written a long time ago and with increasing complexity of the uGFX library we can't remember every decision anymore. inmarket might have a follow-up on this one. After all it can just be a personal and very subjective preference as to point 1) and that it's possible to optimize this. I hope that helps ~ Tectu

The usage text states: "filter ... Remove everything except specified characters."This means that you can specify multiple ranges after the filter keyword and the corresponding file. I assume that filter foo.dat should work. ~ Tectu

The limiting factor regarding multiple filter ranges is the web interface (the online converter), not the actual converter itself. You can manually convert your font using the font encoder which you can find under /tools/mcufontencoder/. The filter parameter takes an unlimited amount of range parameter. We should probably add this option to the online converter as well ~ Tectu

Please have a look at this article: http://wiki.ugfx.org/index.php/Font_rendering It will lead you through the process of adding your own fonts (see the Adding fonts) section. The article contains links to both the online font converter as well as to a wikipedia page that contains tables for all languages to figure out the required filter range. Back when we added unicode support we even created a dedicated article talking about Cyrillic: http://wiki.ugfx.org/index.php/Cyrillic It's currently not possible to specify multiple filter ranges. If the gap is big enough it might make sense to simply generate two font files. We hope that helps. ~ Tectu

That is what the uGFX-Studio is supposed to become eventually: A tool that allows to design a complete GUI within minutes. However, the studio is a long way away from being that tool. The uGFX-Studio is currently a side project and we try to focus on working on the actual library instead. But even if we'd make the studio become our main project it would easily take a year or more to make it become a tool that is powerful enough to handle every-day GUI designing requirements. As inmarket mentioned the uGFX-Studio was initially supposed to become nothing but a simple layout assistance tool. User feedback suggested that it should become a full GUI design suite instead and that is what our goal has become ever since. It just that we currently don't have the resources to put more time into developing the studio. The µGFX library is supposed to be (as the name suggests) a very small and fast library. Whenever we write a single line of code we have to ask ourselves how we can keep both the CPU time and the memory requirements at a bare minimum. That is one of the reasons why everything is modular and why so many features (and sub-features) are completely optional. If you don't need to draw circles your compiler won't even see the circle drawing code. If your hardware provides hardware accelerated circle drawing we will take use of that and so on but everything needs to be able to run on any platform. There are many users who use the uGFX library on a very small ultra-low power device. These microcontrollers often don't provide more than slow 16-Bit CPUs with only a couple of kilobytes of RAM and are powered by batteries way below the 100mAh mark. Every microsecond the CPU is active counts in these applications. That is why the GWIN module only implements very basic functionalities. For example it's not possible to loop through widgets in both directions as we use a singly-linked list for that. Neither is it possible to handle overlapping widgets as you have discovered. However, if you need that and if you can spare the resources you can just write a your own window manager and use it by just calling one simple function that registers your own manager. We are certain that we'll have more than just one built-in window manager in the future so that users with more complex needs will have an out-of-the box solution but we currently lack the man power to do all that and as we provide easy to use interfaces for people to do it themselves we think that things like that are a relatively low-priority task compared to other features. Also note that after all we target embedded applications most of which are running no very low resolution displays. These types of applications usually just require a very static user interface. Unlike with a desktop computer the user usually doesn't need (or expects) to move around windows or minimize and maximize dialog boxes. That is why we spare every byte we can and hence the reason why, for example, you can't dynamically change the parent of a widget. We will never be able to satisfy 100% of all needs but given our focus on providing highly flexible interfaces for customization wherever we can we think that we are on the right track. It's mostly just a matter of time to implement more widgets, more built-in rendering functions and more window managers to meet the needs of more uses. That is the point where you are supposed to write your own custom widget. Custom rendering routines are an easy way to quickly modify the look'n'feel of existing widgets. But when you need behavior that is not already supported by an existing widgets you have to get one step further and write your own widget. And in all cases we focus on providing a highly flexible yet very easy to use interface. The existing facilities such as the GWIN core module, the GDISP module and so on take care of any difficult such as word-wrapping that you mentioned in a previous post. It's just a matter of calling the corresponding GDISP function that draws a string in a box using word-wrapping inside your widget drawing routine to have a widget with a text label that is automatically word-wrapper. If you need an image, just use the GDISP function that draws an image in your widget rendering function and you're done. The GWIN module will take care of coordinate translations, visibility, enable/disable state, event propagation and so on without you having to worry about anything like that. Just create a new widget (you can copy an existing one that matches your needs the best such as the button widget), name it differently (for example "Unit Label"), modify the mouse handling functions to iterate through your four different states and implement a default rendering routine and you are done. No magic (or hacking or work-arounds) involved. And as always we are here to help if you have any questions. First of all it will have an impact on resource requirements. Even if it's just so little and totally negligible for your hardware platform it won't be for others. And secondly - and probably in this case the more important point - it will break the philosophy behind uGFX. The main goals of the uGFX library are to be very platform independent. We want to be able to run the exact same application code on a small, slow and stupid 16-bit microcontroller with a few kB of RAM and on a multi-core high performance platform with gigabytes of RAM and CPUs running in the GHz section. For that we need to do two things: 1. Everything needs to have as low resource requirements as anyhow possible and 2. everything needs to have a highly flexible and modular interface. This results in implementing something like the GWIN widget system by just focusing on the bare minimal functionalities (behavior) for each widget as inmarket mentioned. The thing that will vary from use to use is just the visual representation (the rendering function). In uGFX you can take an existing widget and just change the rendering function or you can write your own widget. You can even write your own window manager and using it is in all three cases just a matter of one line of code. Most other embedded GUI libraries don't provide you with this freedom. See above. We are pretty confident that you won't find an embedded library that will give you more flexibility in any regard. In any case you just should never take the uGFX-Studio into account when thinking about the actual uGFX library. We are light years away from having an uGFX-Studio that can represent the power of the actual uGFX library. ~ Tectu

We didn't know that you were actually using an imagebox for your container background. Using the image rendering function for the container is of course a lot faster as you've seen Note that you can further increase performance by caching the image (in case of it's an encoded format such as GIF). Caching an image keeps the decompressed image in RAM so drawing the image is just a matter of pushing out the pixels from RAM. In case of the STM32F7 with using the LTDC interface this is blazingly fast. Also make sure that your DMA2D is enabled to free even more CPU resources. You can find more information about image caching here: http://wiki.ugfx.org/index.php/Images#Caching ~ Tectu

That is exactly what custom rendering functions are meant for! The widget just implements some logic - the look'n'feel can be implemented by the user of the widget however he wants. Inside the drawing routine you can use any of the GDISP drawing functions. As Word-Wrapping is also implemented inside those GDISP functions you can easily make a button look like a label while still having word-wrapping and so on. Note that in case of your microphone button with the two volume level indicators we'd still strongly recommend writing a custom widget for that. As mentioned before you can copy paste the corresponding parts of the rendering routine of the progressbar widget to save yourself some time. As inmarket mentioned the uGFX-Studio is in a very early stage. It will take ages to make it become a fully featured GUI designing tool. Right now it's helpful to get started and to create quick drafts of your final GUI. Please note that the uGFX-Studio website as well as the "New Project"-Dialog inside the studio itself clearly state that the studio is in a very early beta stage and that it is NOT meant to be used in a productive environment. Right no we don't even guarantee that project files between different studio versions are compatible. The studio has a long way ahead of it but feedback from users like you help us to improve it quickly. We plan to release the first real version within July 2016. ~ Tectu

There's nothing that prevents overlapping images and this should work just fine without any problems at all. Most likely it's just that your GFILE_MAX_GFILES is not set to a large enough value (assuming that you're using ROMFS). This would prevent the second gwinImageOpenFile() call from succeeding which would result in the second image box not rendering the image which would just leave the widget area cleared with the current background color and therefore hiding the image of the underlying imagebox (which would be the case anyway). ~ Tectu

That's true - as long as nothing inside the same part of the uGFX code changes that will make applying the patches fail That's a very interesting use case and we haven't thought of something like that! We'll discuss adding click events for all widgets. Thanks for your feedback! ~ Tectu

We agree with everything that you are saying and the most proper solution to solve your task the best way is to write that custom widget. It will not only take less time now to write that widget (as you can copy paste most of the code of existing widgets) but will also save you time when upgrading to newer uGFX versions in the future. The only argument I can't argue with is that the uGFX-Studio currently doesn't allow you to place custom widgets. I guess that should become a more important task too. Maybe we should even provide a temporary solution for the 0.13 release - not sure. What I can recommend you to do in the meantime (in case of you write custom widgets) is to place a dummy widget such as a console window and then just replace the code (manually by hand) once you're done. After all the studio doesn't offer much advantages besides placing the components at the moment. We appreciate any contributions whether they are bug reports, fixes or just patches for implementing different behavior. Things like this don't only help ourselves to improve the library over time but might also be useful for other users that face a similar problem. ~ Tectu

When you want a background image for your container it is strongly recommended to use the corresponding rendering routine for the container: gwinContainerDraw_Image(). That function takes the gdispImage pointer as parameter and will use the supplied image as the background of the container. That will not only solve your problem but will also be a much more robust and less resource hungry solution. The corresponding API documentation will give you more information about using this rendering function: http://api.ugfx.org/master/group___rend ... adfa961280 ~ Tectu