Undo / Redraw function

[wolf]

Hi all,

I'd like to propose a functionality add-on to GFX:
Imagine drawing a scope like graph with a grid and 2 traces where the traces are to be redrawn at a high update rate, i.e. 30 fps+.
Redrawing the grid and the new traces on each update is slow and leads to ugly flicker - as we all know.
Instead it would be sufficient to store the pixel state before drawing each trace pixel and restore it when deleting the trace.
Nothing new of course - and it would work for any area thinkable - i.e. showing a menu button...
This involves memory allocation - at the simplest static and handling of the buffer, i.e. start / stop / restore...

Modifying gdispDrawPixel() using gdispGetPixelColor() or their respective lld functions can easily do the job of course.

Is there anybody out there who would like to wrap this up into a clean driver with proper typedefs? Maybe with dynamic allocation?

What do you think?

~wolf

[Tectu]

Hello wolf,

Thank you very much for your suggestion. When I hacked the graph widget together, I ran into exactly the same problem. You can observe this here. There are three main reasons why It hasn't been done yet:

• I didn't had time yet. I am currently very busy and I hacked together a small program from a friend from scratch and I just recognized that there is a lot of work to do. Especially when it comes to the GINPUT and GEVENT stuff. Even the docs are missing.
• It's not that easy. Well, it kinda is, but what you need to do is exactly what you described. You need to actually recognize the area on which the user is changing the data. Then you need to backup that region, recalculate the new stuff and pump it out again. Especially the recalculation is not that easy, as I found out myself. Maybe I just had a wrong algorithm in mind and you find some solution which is way better.
• RAM! To backup the data, you need a lot, and I mean A LOT, of memory and not every body does have the 192kB RAM like the F407 does provide it. The feature should therefore be implemented as an actual feature which can be turned of in the gfxconf.h.
• Portability. Not every setup is capable of reading out the LCD's RAM again. Well, that just counts to the point above. Implement it so you can turn it off and everything is okay

Personally, I'd be very thankful if you'd spend the time to come up with a nice solution! Every contribution is appreciated!


~ Tectu

[wolf]

@tectu

Hi all,

Tectu surely is right in all points.
I did some thinking and come up with some ideas to reduce the size of the redraw buffer (and GFX) in general as RAM is scarce:

1.) Introduce the idea of a palette - i.e. one byte represents up to 256 colors (user defined and organized in a look up table) - 8 colors could do for a scope like application
2.) Limit the Window size to 256 x 256 or less, in order to store the x, y, palette data in 3 bytes
3.) When drawing a dot - check the pixel color before - reverse look it up in the table (therefore reduce it to 8 entries), store it together with the pixel coords in the undo buffer
4.)Upon deletion of the last action (say a complete scope trace) just restore the undo buffer to the display
- Done -

There is nothing fancy about it - but it cold help if RAM is the limiting factor on smaller uCs

For what it can do - i added this link: http://sonirajan.com/portoscope-part-7-result/ - turn the sound down though!
It can't do any harm to read through the article - unluckily a bit scattered around on the web site. Also for the hardware guys among the community.
He says that he did it with a.m. undo mechanism somehow.
This runs on a STM32F103 with the HY32 touch and FSMC - just amazing.

Have fun!

p.s. - I'll try to implement it and will keep you posted - once i get the time

[Tectu]

I know the portoscope, I have watched that video many many times, it is very impressive and amazing.
If you find any time and motivation, feel free to give it a try. I'm thankful for any contributions, currently, I just don't have much time myself and all the time I have for GFX goes into docs and cleanups.

EDIT: I think it would be best to directly integrate this into the graph widget of GWIN?


~ Tectu

[inmarket]

Have a look at the oscilloscope implementation in the GADC and GAUDIN demos. The demos draw an oscilloscope trace (in my testing on my slow board using a SPI interface LCD) at over 90 frames per second. It also only uses one pixel of RAM per x value (about 128 bytes in the GADC demo).

It shows how you can do trace redraw without allocating a full RAM display buffer.

I have thought about the potential for allowing an optional "RAM" based display surface. This has a number of technical difficulties:

• It uses lots of RAM (lots and lots and lots). One of the big advantages of GDISP currently is that it does not require a memory mapped or memory backed display - unlike most other graphics libraries, and is therefore suitable for embedded controllers with very little RAM.
• Unless the pixel format is exactly the same as your display hardware GDISP cannot currently support it as the API currently only allows one pixel format. To change this would cause MAJOR changes to the API and significantly complicate the API. It would also require that drawing routines for every pixel format be included - significantly raising the size of the GDISP library itself.
• Having two display devices is currently not supported in GDISP and again it would probably require significant API changes. It might be possible to create a RAM based display device that calls another physical GDISP driver to support drawing on a portion of its virtual desktop space but this is getting very complex.

Whilst there may be a way of getting round these difficulties - it is obviously going to be a lot of work. As it is not a "highly demanded" feature it is definitely on the back-burner for now.