Joel Bodenmann

When a container gets redrawn, it first clears the entire client area and then iterates through its list of children and redraws each child. This means that whenever you move your element by even just one pixel and in the container then call gwinRedraw() everything gets redrawn and that is what causes flickering due to low hardware performance. The implementation of the currently existing container doesn't allow partial redraws. Depending on your needs I guess the best solution for you is to write your own (container) widget from scratch that is specifically designed to contain a number of widgets that can be moved around and it will just redraw the background area that needs to be redrawn. Of course the actual implementation depends a lot on your needs. When the background is just a solid color then it will be very straight forward. If its an arbitrary pattern that is not known then it will be a bit more difficult as you basically have to buffer the entire background. Sadly there is no official "how to write your own widget" guide at the moment. However, it is rather easy and very straight forward. Basically a widget is nothing but a table of functions that get called by the GWIN module. There's one function that gets called when the widget is supposed to get redrawn, one function that informs the widget about touch coordinates, another function for when a key press event happened and so on. Nearly all of these functions are completely optional. As there are already a lot of different widgets available you should have enough examples to get started. If you have any question regarding the implementation of widgets we are of course very happy to help you where ever we can. I hope that helps. ~ Tectu

Yeah, we have seen that problem many times in the past. The ILI display driver family is a big mess. Anyway, happy that you got it working! ~ Tectu

Hello Kenneth and welcome to the community! I just verified that the gdispFillCircle() function is working as expected. Therefore, this must be an issue inside the driver that you are using. As every drawing function in uGFX, the gdispFillCircle() function will try to use hardware acceleration wherever possible. As the ILI9325 doesn't support hardware acceleration for circle drawing, it will rely on using hardware fills (gdisp_lld_fill_area()) or streaming (gdisp_lld_write_xxx()). Looking at the current state of the ILI9325 it seems like it doesn't support hardware filling either. Therefore, the problem must be inside the streaming function. To verify this, you can disable the hardware streaming support in the drivers configuration file (/drivers/gdisp/ILI9325/gdisp_lld_config.h). You should then be able to draw filled circles without any artifacts. Once you confirmed that that's the problem, the next step will be to figure out whether the problem is inside the actual driver itself or in your board file. As there's not much happening for hardware streaming in the driver itself (it's just wrapping the calls), the problem will be most likely in your board file. I hope that helps. Please do not hesitate to ask should you have any other questions. ~ Tectu

That sounds good to us! We are happy to answer any of your questions to help you figuring out what causes the problem with the F7 port. It's just that we are currently drowning in work so we don't have time to get to it ourselves. ~ Tectu

Glad to hear that you got it working - does this actually solve your issue/answer your question or should we still have a look this when we get to it? ~ Tectu

The built-in graph widget only provides very basic functionalities. It doesn't have an internal list of points. Each time the graph is redrawn you must redraw your points manually using gwinGraphDrawPoints(). This means that if you want to scroll your graph you'll have to shift your points manually using the process you described. If you have needs for a graph that can shift points I would strongly recommend implementing your own graph widget! ~ Tectu

Displaying multiple graphs at the same time is not a problem at all. You can have as many windows and widgets on your display at the same time. Just think of the graph window as if it were a regular widget like a button or a slider: You can have as many of them as you want, working independently. That is also why I used the term "graph widget" instead of "graph window" in my first post - to avoid confusion. ~ Tectu

uGFX comes with an existing graph widget: http://wiki.ugfx.org/index.php/Graph Examples: https://i.ytimg.com/vi/WcNgBEWWnrc/maxresdefault.jpg http://wiki.ugfx.org/images/b/b4/Graph_demo_640x480.gif Whether you want to use the existing graph widget or not is up to you. The graph widget is one of the first widgets that we created. It isn't the most used thing in the uGFX library and therefore we didn't spend a lot of time extending and optimizing it. Don't get me wrong, the code that is there works very well and there are many people who use it. It's just not the holy grail for all your graph needs. Writing your own graph widget would be very easy as the graph itself is not a widget but a window (read the GWIN article in the wiki for more information). The basic difference is that a window doesn't take any user input while a widget does. Therefore, creating a custom graph window is just a matter of using the already available GDISP drawing functions to make it look and behave like you want. You can look at the existing graph implementation (/src/gwin/gwin_graph.c) to learn how to implement your own, it's really straight forward. Please do not hesitate to ask should you have any other questions regarding the existing graph widget or writing your own. We are happy to help wherever we can. If you decide to either write your own graph from scratch or extend the existing one, we would of course be very happy if we can add your contribution to the library so others will benefit too ~ Tectu

Hello SimonRogers and welcome to the Community! Sorry for the late reply. We are currently very busy. Sadly I can't promise you that we'll have time to take a look at this before Monday morning. The last time we checked the demo worked the way it should. There are also a lot of users that successfully use the uGFX library with cyrillic fonts so we don't expect there to be a big issue. Did you try to use a different font? This article explains how you can use any Cyrillic TrueType font that you can find on the internet: http://wiki.ugfx.org/index.php/Font_rendering ~ Tectu

Hello Sillvers, You change the buttons text like you change the text of any widget by using gwinSetText(). API Documentation: http://api.ugfx.org/group___widget.html#ga0d2b40a6ef33c7be87f77876a94b9561 Please do not hesitate to ask should you have any other questions. ~ Tectu

Hello Kent and welcome to the community! I'll fix and update the project over the weekend. Sorry for the inconvenience! ~ Tectu

Nothing in uGFX is being redrawn periodically. When using a plain gdispImage you have to redraw the image yourself when it needs to be redrawn. When you are using the ImageBox widget the image will automatically be redrawn if it needs to, eg. if something covered it and moved or when the visibility changed. In either way, there are no periodic redraws. ~ Tectu

Well, glad to hear that you got it working Let's hope we'll be faster next time ~ Tectu

We are glad to hear that you got it working! Happy to hear that you like the uGFX library ~ Tectu

Using RLE fonts is the way to go then ~ Tectu

Glad to hear that you like what you see Note that you can run uGFX on any RTOS (or bare metal without any operating system at all). The decision whether you want to use uGFX or not shouldn't be influenced by the underlying system. Please do not hesitate to ask should you have any other questions. We are happy to help where we can. ~ Tectu

1. The most proper, most reliable and most portable way of doing this is creating your own widget that allows to input a date/time. The widget would behave just like the other widgets such as the buttons and the sliders: You can create an instance, you can place them anywhere on the display and you can give them any size. The widget would sent an event through GEVENT when the date/time has changed just like the slider sends an event when the slider position has changed. You can also add different functions eg. to query the current date/time and to change from 12 to 24 hour mode. Those are of course not necessary but writing a real widget helps you to add functionalities in the future while being completely portable. Writing your own widget is not as complex as it might look at the first glance. Essentially it is just a VMT (table of function pointers) where you register your functions that handle touch inputs and so on. Everything is nicely commented and documented. As there are already quite a lot of different widgets you have many different examples that will help you to understand how to write your own widgets. We are also happy to answer any of your questions (please make a new forum thread for that). I would really encourage you for writing a real widget for this. The widget class is really just a container and it won't be more difficult than writing this manually. There is one function that renders the widget and in that function you call gdispDrawXxx() and gdispFillXxx() functions just as you would outside of a widget and there are other functions that tell you when a touch happened and at what position. It's straight forward - really. Just read some of the existing ones and let us know when you have any questions 2. Using the gwinButtonDraw_Image rendering routine is the correct way of doing what you want to do. You can replace the image at any time by just calling gwinSetCustomDraw() with a different image pointer. That function will also take care of redrawing the button widget so you don't have to take care of that yourself. Important note: Many people want to change the image during runtime because they want to draw different images for the pressed and the released state. However, that is not necessary. .The gwinButtonDraw_Image already takes care of that for you: The image you pass by gwinSetCustomDraw() can either have one time, two times or three times the height of the actual button widget itself. When the image is twice the height than the button then the top half of the image is used for the 'released' state and the bottom half is used for when the button is in the 'pressed' state. The same applies to when then image is three times the height: Top for pressed, middle for released and bottom for when the button is disabled. Here's a very basic image just to make sure that you understand what I'm trying to say:

Multiple things need to be kept in mind when considering image caching. Whether it make sense to cache an image depends a lot on the user hardware/architecture as well as the application itself (how big the image is, what format/encoding the image is using, how often it needs to be drawn etc). As inmarket already said, caching an image means that a chunk of RAM will be allocated to store the entire decoded image. A decoded image is essentially a table of pixel values in the display controllers native color format. Working with an RGB565 format would mean that two bytes per pixel need to be allocated. A plain BMP file is already pretty much that. After a small header it's essentially a table of pixel values. This means that in terms of performance (as in saving CPU cycles for decoding) you won't gain anything when caching a plain BMP file. The next thing to consider is memory speed. This depends on the architecture of your device and the actual components used. In your case you're having both the ROM that stores the image as well as the RAM where you'd store the cached image on the same bus/peripheral (the FMC). Assuming that reading from your SDRAM is as fast as reading from the NOR would mean that the main gain would be that you don't need to spent time changing the peripheral configuration to switch between the two memories. Another important thing to keep in mind is hardware acceleration: In your case the DMA2D peripheral would allow to directly blit the entire image 1:1 without any CPU time involved at all. This is obviously a huge benefit and would save a lot of CPU time. In my opinion in your case it boils down to how often you need to draw the image, how big your RAM is and how fast you can access the NOR. I hope that helps... somehow. ~ Tectu

Hi! Thank you very much for your feedback. We appreciate it a lot! We see what you mean and we will definitely do that. It sounds like a great idea! However, this might take some time as you said yourself that's quite a bit of work. We'll let you know once we're done! ~ Tectu

Hello Sillvers and welcome to the community! The file/folder structure and the Makefiles provided with the library are very well tested and known to work without any issues. As inmarket already mentioned you're most likely pointing the GFXLIB variable to the wrong place. This variable should point to the top-level directory of the unmodified uGFX library directory. You can find some additional information about this here: http://wiki.ugfx.org/index.php/Getting_ ... grate_uGFX Let us know when you have any other questions. ~ Tectu

Glad to hear that you got it working! We would love to include the corresponding drivers and board files into the repository Is that Linux driver now working nicely as a generic driver or what's the current state of that? ~ Tectu

Sadly he's not able to help as he's currently on a trip (vacation). However, he sent me the files attached (GINPUT driver, board file, test project). He used this on a 3.2 Linux. The uGFX version he used this with was something between 2.3 and 2.4. I hope that helps you somehow... Please let us know how this turns out. ~ Tectu linux_ginput_event.zip

Somebody I know has already written a generic event based touchscreen input driver for using touchscreens with uGFX on a linux system. I will ask him whether it would be possible to share that driver. That would save you some pain. ~ Tectu

Hello sordfish and welcome to the community! It looks like we forgot to apply these changes. I put it on the ToDo list! Thank you for reminding us ~ Tectu

You might want to store your calibration values once you performed the calibration. This way you can 'boot up' (starting uGFX by calling gfxInit()) without the need to calibrate again. Information on how to use the calibration interface can be found here: http://wiki.ugfx.org/index.php?title=To ... alibration ~ Tectu