inmarket

If nothing is being shown with a particular font then this is an ideal place to start debugging. The primary advantage of prototyping using a desktop operating system like linux or windows is that you can use the ide debugger and thus more easily debug your application. With regard to multi threading, this is required by any windowing system except the most rudimentary simply by the nature of what you are doing. As mentioned before it is the input system that requires the multi-threading not so much the drawing. Whilst I have ideas to remove that requirement it is not an easy task. Linux and win32 emulations have been well tested, win32 probably more than linux. I would be surprised if there was a significant issue in that area simply as for the reasons above it is these two platforms that most of the gwin system was written on. That is why I was looking at possible compiler flag issues as we don't seem to be seeing the same problem. Can you please write a test demo (something like one of the demos in ugfx) that demonstrates the problem - the simpler the better. We can then compile the same program and see if we get the same result. If we do we have something to debug, if not then we know it is something about your build environment.

With regard to the initial dynamic allocation of the text from the init structure, if this is a problem pass null initially and then use gwinSetText afterwards to set the text with FALSE for the last parameter.

Sorry i missed the static on the variable definition. I however just noticed you are compiling under linux. Are you compiling using the thread safe c runtime library? I think the compile flag is gcc -pthread but please check the doco first. This flag needs to be specified as well as including the pthread library. Alternatively try compiling with our make system which (should) get it right.

The problem I think is with the last parameter to gwinSetText. This last parameter tells the function whether to copy the string because it is not a static string. As your buffer is allocated on the stack you should be using TRUE for that parameter. You might also want to look at using the snprintg function provided by ugfx. Using it instead of snprintf should compile a lot smaller as the whole stdio package from your standard library doesn't need to be included. Stdio is usually quite big.

Fantastic. When my display arrives I will know what to do.

I have not had time yet unfortunately. Work has been extremely busy. There has however been something else that has come up that may be an issue... Try using GOS_RAW32_HEAP_SIZE to invoke the use of the raw32 memory allocator. Some third party (including ones like the arduino versions) cannot handle being called with a non - native stack base and thereby cause the application to crash in unexpected places. If that doesn't work please let me know and I will make a bigger effort to allocate that time I promised.

Not sure why the axis and grid are not being displayed without the clear first - they used to. This is a very old demo however and has not been checked in a long time so I will debug to see what is happening when I get a moment. Theoretically as the screen is already clear it shouldn't be necessary to clear it again. I suspect some of the widget flags are no longer being initialised correctly. Glad you found a work around in the mean time.

Yes a pointer to a pre allocated object can be passed to the widget constructor. It is indeed designed for smaller memory systems that need to very carefully control memory allocation. It also saves the memory allocator overhead. Similarly widget strings can be passed in as static strings or copied to dynamic memory. There are however some strings that are always dynamic for example list box strings. Widgets such as the image widget also use dynamic memory for things like image decoding. Thus most widgets can avoid dynamic memory allocation with careful programming - but not everything. Whenever dynamic memory is required the system always uses gfxAlloc and gfxFree. These are implemented by the gos layer and should be able to be called safely anywhere in the gfx code. In your case however the arduino malloc and free do not operate correctly unless the code is running on the native stack. This is a bug in that implementation but is not infrequent in embedded libraries. One bad implementation gets replicated into lots of platforms. It is for the lack of good memory allocation routines that the alternative raw32 memory allocator was written. It solves that problem nicely fixing those platforms that have no suitable routines and those that are buggy (such as the arduino library version). I can't complain too much about their implementation however as changing the stack is not a common operation and so it is highly unlikely that situation has been tested well by the arduino library writers.

Compare the label padding to the number of pixels you are moving the label.

Depending on the justification specified. Left will put it hard left, center will put it in the middle (plus or minus a pixel because of rounding) and right puts it hard right subject to inter - character spacing.

Just a thought... If you put a space at the beginning of the label it may remove this problem. It could be caused by the font being hard up against the left edge of the label but the right edge may have a single pixel space due to inter - character gaps as defined by the font.

I don't know. Some debugging of the move redrawing would probably be required to find out.

Very nice project and a great demo of a custom widget. Well done!

Very nice video!

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.