Joel Bodenmann

It's not using the same rendering function because calculating the width of a string is very heavy operation. It takes a lot of time to complete as it is not a deterministic operation. The actual string width depends on many factors such as kerning. There's no way of quickly telling the width of a string beside actually rendering it. Therefore, directly rendering the characters to the display is a lot more efficient than first calculating the string width. However, that is simply not possible when center aligning something because you don't know at which position you have to start. With left and right alignment you know where to start. Having a dedicated function for right-alignment rendering allows to directly render to the display like with left-alignment too without the need to compute the width first. Additionally having a separate function for rendering right-aligned strings would allow to render RTL (right-to-left) languages properly too without those calculation overheads. The main reason for this is to keep the API consistent. All GDISP calls have a DrawXxx() and a FillXxx() equivalent. No need to break the API for the string functions. We like it consistent. Of course you could argue that one can have one function with a parameter that specifies that and then a wrapper function to save a little bit of code space but as mentioned in an earlier thread where this question showed up another reason for this is that some compilers have had very hard times working with conditional function pointers. That sounds about right Font rendering is a heavy operation. That is why often pixmaps are used to render strings internally before stuffing them to the actual display. That drastically reduces flickering and increases performance a lot.

Reading just one specific pixel is not possible as the image gets decoded on the fly. Even if the image is cached the cache is specific to each image so we don't provide any API to access that. There are two workarounds to this: Use the native format to store your picture. As the native format is uncompressed by definition it's possible to access any pixel at any time. However, we don't provide an API for that, you'd have to write that yourself. Also note that this can be horribly slow depending on where your image is located and so on. After all, the main reason to use a native image format is that it doesn't need to be cached. The better approach would be to take your regular image, render it into a pixmap and then access the pixels from that pixmap. The pixmaps provide API to get direct access to each pixel. This would probably be the best solution. Regarding your second post: The studio allows you to specify files that get included in the generated romfs_files.h in the settings. You can specify your path to the BMP there. However, the studio won't open the image for you. We should probably think of introducing a resource manager for the next release where every resource (font, image, widget style, ...) is located in a central place. Please feel free to leave your suggestions in the corresponding uGFX-Studio forum. Yes, containers can have image backgrounds. You will find all about that in the API documentation: http://api.ugfx.org/group___renderings___container.html Labels don't have a transparent background rendering routine for several reasons which have been discussed before:

There are no explicit examples for that because they wouldn't be very portable. You can use any of the existing image examples you want. All you do is enabling the native format in the configuration file - everything else stays the same! You can find the definition of the native format header in our wiki: http://wiki.ugfx.org/index.php/Images#NATIVE If you are having any issues getting this to work please do not hesitate to show us your file(s) so we can have a look.

The GNU ARM tools. Most people use this: https://launchpad.net/gcc-arm-embedded

It seems like the toolchain that you are using doesn't provide support for the Cortex-M7 architecture. You might need to update to a more recent version of GCC. I think that you need to get at least 4.9.3 for Cortex-M7 support.

This issue was fixed in a chat. Dolence will post his final board file here later so other people can use that as a reference.

I don't think that that is true. The last time I used EmBitz with Makefiles it worked like a charm - no issues debugging. Note that the debugger just relies on parsing files. Makefile just controls how these files are built. Once all files are there the debugger is happy.

Yes that is correct. You never ever want to call gwinDrawXxx(), gwinFillXxx() or similar functions inside a GWIN rendering routine as that would cause the widget to be updated again and therefore creating an endless-loop. If you are using EmBitz with a Makefile then just integrate uGFX into that makefile! uGFX comes with a built-in Makefile system. You just have to include the main makefile and add a variable to your sources and include path lists. That is explained here: http://wiki.ugfx.org/index.php/Getting_Started#Makefiles And for a real-world example thake a look at the ChibiOS/RT example: http://wiki.ugfx.org/index.php/Using_ChibiOS/RT

I'd recommend to write your own graph widget (it's actually a window, not a widget so it's even way simpler). That custom graph widget will contain a list of whatever it needs to keep track of. Then in the rendering routine you clear the area, draw your own axis, grid, labels and so on and then render your data on top of that. This gives you maximum flexibility at the highest possible performance (from the GWIN point of view). For example, if you need a rolling-graph feature then you can have a push_back() function in your graph widget that will append a new point and shift all existing ones to the left. Possibilities are (nearly) endless From the architecture point of view you should not care of rendering the widget internally itself first and then show the result at the end. That is what the GWIN and the GDISP module take care of. If you want to optimize this then Pixmaps are definitely the way to go. Note that the single-file-inclusion mechanism is just a mechanism we provide for stating quickly. It has a couple of limitations such as the pixmaps and support for custom fonts that have not been resolved yet. It is ALWAYS possible not to use the single-file-inclusion and therefore being able to use the pixmap feature.

No, you don't have to increase the display count. All you have to do is enabling the pixmap in your configuration file by setting GDISP_NEED_PIXMAP to TRUE. Note that there's currently a nasty bug/limitation that prevents you from using pixmaps when using the single-file-inclusion method. More information can be found here: ~ Tectu

Here you go, from naftilos76: ~ Tectu

That's a custom widget, not an existing one I am afraid. As mentioned in the other thread I'll ask the guy to share the sources as this was meant to become an open source project anyway. ~ Tectu

I know that guy, he's an awesome and very friendly person. I'll ask him to share the source files Might take a couple of times until he answers, tho. ~ Tectu

Thank you, we will have a look at the demo and fix whatever needs to be fixed :ugeek: ~ Tectu

As the graph doesn't keep track of the data itself (for various reasons) clearing the graph and then manually redrawing the actual data points is the correct way. Decoupling the data acquisition and the rendering of the data as per your method is also a very good idea. The flickering occurs because gwinClear() will clear the graph (fill the entire area with the background color, then draw axis and grids) and then some time passes until you write your new data. This time in-between those two operations cause the flickering. Ideally, the rendering of the entire graph would happen off-screen and the result is copied in one operation to the frame buffer. This can be archived by using Pixmaps which provide dynamic virtual off-screen displays to which you can render just as to any display and once everything has completed it can be blitted into the frame buffer. However, note that depending on your hardware (memory bandwidth, coupling between framebuffer memory and RAM, ...) can cause to actually lower the performance. Another solution is to write your own graph widget which would maintain a list of the data-points as per your needs. The graph widget that comes with the uGFX library is very old and doesn't provide many features. Also, it is hard to write such a specialized widget that is still generic and universal usable. Can you tell us which scope demo you mean? Over the time many users have written a lot of different, very awesome oscilloscope demos If you are referring to the demo that samples an audio input via GAUDIO and draws the volume line/graph, then that demo can be found under /demos/modules/GAUDIO/oscilloscope. However, that demo is very old and it was created even before the graph widget existed, so I assume that you are referring to another demo? If you tell us which one we might be able to tell you who wrote the demo and what the trick was to get such amazing performance out of it. ~ Tectu

The frame widget sends the following event when it gets closed: GEVENT_GWIN_CLOSE So in your event loop, just listen for that event as you do for any other event (button press, slider value change, ...) and you should be good. The overlapping that containers manage is the overlapping between the parent and the child, not between individual children. So everything mentioned about the window manager above still is the case. ~ Tectu

There's currently no drop-down widget that comes with the uGFX library. Neither are we aware that any user ever created one. Which demo are you referring too? ~ Tectu