inmarket

Multi-threading was pretty much required not so much by the widgets but by the input subsystem. It is surprisingly difficult to do input particularly touch without timers and multiple threads. I have some ideas for removing that current dependancy but there are always compromises and it will certainly raise complexity of some components to do so.

One more note... I notice you are doing some inverse square root operations. You might want to try the routine in GMISC for this as it is a LOT faster than any standard maths library. It is code that I picked up from the gaming industry and is used in the bouncing ball gdisp streaming demo.

Great that you found a solution. I will put that back into the repository for the arduino port of gos. Just another thought for you... In your main loop you are doing a timer comparison to run update every 100ms. Let me suggest to you to use gtimer to run your update every 100ms. The geventEventWait can then use INFINITE for the timeout period and that loop does nothing but handle events. The multi threading is not going to be an issue for two reasons, 1) gwin is designed for that, and 2) your class should be safe as the threading on your platform is cooperative.

Does the same behaviour occur in X with the same redraw flags? If not then it is possible the arduino memory allocator is stack sensitive (i have seen this before although it shouldn't happen in any well written host routine). Unfortunately the only way to test it is to replace the memory allocation/free routines in the gos module with the alternative routines from raw32 gos. Those routines require you to give it a one off big block of memory at init time and it will manage that block thereafter.

Just a note on the gfxYield, if you replace the 0 in the geventEventWait call with a 1 I suspect the gfxYield will not be needed.

It is certainly possible there is a bug in that area. It is not not often used by most gfx users so it is possible there is a bug there (i wish we always wrote perfect code). I will look closer tomorrow As it is getting a bit late here.

GfxYield or gfxSleepMilliseconds is required to give other threads a chance to run - in this case the gtimer thread which is responsible for redraw (as discussed above) and for polling input devices such as your touch panel. The reason the yield is required to make other threads run is that you are running bare metal and the threading implemented for the bare metal GOS is co-operative rather than preemptive.

Perhaps stack on the main thread. Redraw immediate redraws the moment it is asked for rather than delaying it to the timer thread. That has the effect of more immediate redraws but it is less efficient (more overdraw) and requires more stack space on the main thread.

Nice video. I noticed some redraw delays in a few instances. If that is really on the display and not just a video artifact have a look at the gwin window manager redraw options for your gfxconf.h These trade of stack depth required, visual flashing, and visual responsiveness. You might find a setting that works better for your application.

Of course. That makes lots of sense. Just change the x, y (provided they are still inside the patent container) and then redraw the parent container

Saving in binary is very quick and easy, just write the struct to the file. Binary however is difficult if you want someone to be able to edit it when the sdcard is not in your device. In that case you should use some text format. If you need to use a text format a function to look at is gprintg which is equivalent to fprintf except it uses gfile.

I also have a ssh1106 module on order. I will write a driver for it when it arrives if you can wait.

Unfortunately I am in Australia. I have done the next best thing and ordered the same module. My guess is that it will take 2 to 3 weeks to arrive though. My reasons for suspecting it is spi is a) the labelling of the pins, b) the aliexpress advert uses both i2c and spi in the description (wwhich was the same with the previous product I purchased that was spi) and c) it is not working with normal i2c protocol.

Looking at the module, it looks identical to a module I purchased. I strongly suspect that this is a SPI module rather than a i2c module. Certainly the one I have that looks identical is spi. Try it with spi first and get back to us if that doesn't work and we will look closer at the i2c side.

I'll have to look into the module and the other reference in more detail when I get some more time however I thought I would quickly reply on the other question. We don't have a software bit banging i2c implementation in the examples that I know of. We do however have a software bit banging SPI implementation. Have a look at the UEXT board files for the SAM7EX256 board. You may be able to modify that to suit your needs.

Overlapping window redrawing is something that ugfx doesn't handle because the code to do so is very complex and it requires fairly large ram tables (not good for an embedded platform). In practice this is seldom a problem due to containers and rudimentary support for Z order. Your use case however is slightly different and it is why you see the artifacts when dragging over a button. You solution is probably the best one, just to redraw the screen afterwards. With regard to parent relative coordinates, widgets always store their coordinates relative to the display. The reason for this is that it makes drawing in each widget much simpler. GwinMove, being a user api, takes coordinates relative to the parent. Your solution to correct the coordinates is the right approach however you also need to subtract the top and left border width. There are calls to get the border or at least the inner width and height of a container. Look at the code for gwinMove itself. Creating an api to get the relative position is probably a good idea. I will look at that when I get some time. Nice work.

I will look at it in the next few days. Sorry i can't get to it earlier, it's just very busy at my real work after the easter break.

You are looking in the right place. Widgets are in the place they are put. The application can move them with gwinMove but that is something not well tested as the moving of widgets seldom happens in embedded platforms (or even desktop applications except in dynamic sizing forms). It should be possible however to copy the label code into your project and modify it to get the functionality you want. You are indeed looking at the right spot in the code to be doing something like that.

Its possible. Can you please post a cut down version of your project (the minimum necessary to replicate the fault) and describe your hardware. We will try and help with debugging.

A GWIN virtual keyboard widget has been added.

We have been having some similar reports from other users. They solved their problems by changing their compiler optimisation flags from -O2 to -O0. Try this first and see if it solves your problem.

Well done with the touch driver. When you are happy with it please email the code and we will add it as an officially supported chip to the repository.

These optimiser bugs we really should find so we can rearrange the code to fix it. Any help you can provide with that would be appreciated. The last one I found was a ternary operator being used for an integer between two values test. The optimiser was completely stuffing up the range test. Unfortunately the test was in a macro in an chibios header file so outside our control. I ended up rewriting the block of code using the test to get around it.

It definitely could be an optimisation issue. We only compile with -O0 due to significant problems we have had with other optimiser settings in the past. Unfortunately the gcc optimiser is quite buggy.

Wonderful! Another compiler optimizer bug. We have seen a few of those. Mostly we fix these as we find them (by code rearrangement) however different versions of compilers, let alone different compilers can have different optimisation bugs.