uGFX 3.0 features ?

[chodzikman]

Is there a list of TODO / new features for version 3.0 available? Also what is planned time to officialy introduce it?

I would like to convince my company to purchase the licence, but at the moment it lacks some features which surely will be pointed out (most importantly double buffering for LTDC driver - just by now I can see screen tearing on simple graphs, also anti-aliasing on primitives as an option).

Don't necessarily want to feed you with the list of features which hopefully are already on the schedule. On the other hand, regarding release date, don't want to bother implementing needed functions on older version and then challenging compatibility issues.

Also at this moment if I want to contribute some code to the project, I risk messing with your plans / vision.

[inmarket]

V3 currently has no planned release date although I am hoping around June/July. V2.8 and V3.0 will be released simultaneously with V2.8 being the last V2 release.

The major differences so far with V3 are:

1. A new gdisp driver interface. This will have improved efficiency, improved features, can all be added to a project via config variables, and is compatible with single file make. Adding a gdisp driver at link time is no longer required.

2. Renaming of certain types and color constants to remove name conflicts.

V3.0 has a GFX_COMPAT_V2 config that is set on by default that will enable existing uGFX applications to compile and run (but not drivers).

As part of the gdisp driver rewrite for V3.0, it is planned that the 2nd layer of the STM32 LTDC will be exposed and this should allow all sorts of groovey effects (including double buffering).

One if the main purposes of V3 is to move to a point where the entire uGFX (including drivers) can be built using single file make. That may happen in V3.0 but more likely it will be V3.x. Unfortunately the largest amount of queries we get is "how do i add uGFX to xyz IDE". Single file make solves those issues and also significantly speeds up the compile. It also aids technology that we are working on for the new version of Studio.

If you have a list of things that you would like to see please send them. We can't guarantee anything but if it fits the development plan we will add it.

[chodzikman]

Ok,

thank you for the information, it's a start.

So few more questions:

-Is V3 branch in repo usable at this moment or not at all?

-If I want to contribute some high level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write more advanced graph widget)?

-If I want to contribute some low level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write driver-dependent advanced anti-aliasing for primitives)?

-Are you interested in low-level double-buffering LTDC for 2.x? It would behave like this: Declaring two framebuffers and two pointers, writing to buffer which is hidden, when finished, buffer pointers are swapped and DMA mem2mem is requested to update hidden buffer. It will prevent screen tearing in some rapid redrawing stuff without changing any high-level behavior

 

If you want to gain more contributors to the library itself, I'd recommend you to insert a guide on the wiki, at this moment it feels a bit like you want to develop core of library by yourself and let users contribute some high level stuff (which is understable for me, but it would be better to make it clear).

 

 

 

[Joel Bodenmann]

3 hours ago, chodzikman said:

-Is V3 branch in repo usable at this moment or not at all?

It's far from complete. Don't touch it. As far as I know @inmarket managed to get it compiling a couple of days ago but nothing is working yet.

 

3 hours ago, chodzikman said:

-If I want to contribute some high level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write more advanced graph widget)?

Yes, contributions are always possible and always appreciated from our side. As mentioned v3 is far from usable and even further from ready. There's no point in contributing anything to v3 yet unless you want to start actively developing for v3. Furthermore, as mentioned, v3 is backwards compatible to v2 except for the drivers interface. So any high-level stuff like an advanced graph widget will be fully portable to v3.

 

3 hours ago, chodzikman said:

-If I want to contribute some low level features, is it possible? Should I do it for V3 or V2? (perhaps I'll write driver-dependent advanced anti-aliasing for primitives)?

Same as above except for the fact that v2 drivers won't be compatible with v3. However, as mentioned in another forum post somewhere we still accept (and appreciate) any new driver contributions for v2. Prior to releasing v3 we'll port all v2 drivers that have been included to the v2 repository to v3. Therefore, everything you contribute now will be ported & maintained by us.

 

3 hours ago, chodzikman said:

-Are you interested in low-level double-buffering LTDC for 2.x? It would behave like this: Declaring two framebuffers and two pointers, writing to buffer which is hidden, when finished, buffer pointers are swapped and DMA mem2mem is requested to update hidden buffer. It will prevent screen tearing in some rapid redrawing stuff without changing any high-level behavior

Yes, we are highly interested in that. We simply lack the manpower at the moment. As explained above contributing to v2 is absolutely no problem and actually the "recommended" way.

 

3 hours ago, chodzikman said:

If you want to gain more contributors to the library itself, I'd recommend you to insert a guide on the wiki, at this moment it feels a bit like you want to develop core of library by yourself and let users contribute some high level stuff (which is understable for me, but it would be better to make it clear).

We're happy for any kind of contributions, really
There are not many contributions to the core itself because contributing to the core requires a bit more knowledge than lets say a new widget or a new driver where those interfaces are clearly documented and isolated. We do get contributions to the core itself regularly (and even bug fixes) but those usually come from engineers that work with µGFX in a commercial project. They usually have a support contract and don't show up on the forum here. I'd say about 75% of the people on this forum are hobbyists and makers that use µGFX "as is" from the point of view of the core and "simply" add new drivers and widgets.

 

I hope that helps. @inmarket might correct me if my v2/v3 information above is inaccurate. He's currently focusing on v3 development while I'm busy with getting the new µGFX-Studio ready.

[inmarket]

Yes, what Joel said is correct. We are happy for any contribution at any level.

I am happy for either V2 or V3 contributions. V3 contributions are easier for me as I don't have to port the type names etc to V3 but they will obviously not be available for most users until V3 is released.

V3 currently compiles for Win32 to the point where it can run the basics demo. Most of the rest of GDISP is broken as it hasn't been ported to the new driver interface. In fact some of the finer details of the V3 driver interface are not settled yet eg. Whether the driver or the gdisp layer updates the window cursor (currently the driver). If you are interested I would be happy to talk to you outside of the forum on the design aims and efficiency comprimises that are being made there.

I am currently in the process of moving display orientation support from the driver into the gdisp layer and introducing the concept of a scan direction for the driver. This will enable orientation support on all displays with better efficiency for those that support scan direction changing.

Win32 will remain the only driver capable of running V3 until the interfaces are finalised. I tend to try and leave the V3 repo in a compilable state (although currently only for the basics demo) so if you are feeling brave you are welcome to try it.

Once I have the GDISP low level layer finalised (anything that needs to take the driver lock) there will be lots of work porting drivers etc and any extra man power would be highly appreciated. Any new features that don't require GDISP low level code are also very much appreciated. As an example I have a bunch of code with new trig highly efficient trig api. That needs to be tested and integrated and V2 compatibility thunks added but obviously the new driver interface is currently taking priority. 

However you would like to help or contribute we would be very glad.

[chodzikman]

Ok! Thank you for the info.

I want to add this double-buffering feature (I'll have some time for it within two weeks hopefully - next week I am at Hannover fair...), but I have just jumped through code and the way I want to implement it would require some kind of additional trigger from higher layers - It could be either sent automatically on redrawing widget finished or manually by user.

It can make it a bit ambiguous for programmer (manual buffer-swap triggering) or (in case of auto-triggering) make some visible delays between drawing each widgets on lower memory throughput (for example 4 big widgets in each corner of the screen, 8-bit data bus for SDRAM and 4.3" display) due to DMA buffer copying time. Maybe you have some other ideas / advice?

As far as I understand, If i were to implement it with the spirit of existing code, I should add definition option for LTDC in main config file and include my code in corresponding ifdefs. Should I know about anything else regarding name convention or anything else? Again, perhaps there should be a guideline for contributors.

Perhaps in V3 some generic events/flags from higher levels to the driver should be implemented to create generic way to make display drivers rely on some of driver-specific synchronisation features? (Maybe it already exists and I haven't found it)

How it behaves now on larger LCD TFT drivers with slow serial communication? Is it efficient enough (not visible) to draw pixel by pixel instead of sending longer packets?

Regarding contribution to V3 - I don't want to promise anything, but I find it interesting to work a bit on things you written in my spare time.

[inmarket]

To implement transparent double buffering using dma to transfer the display would most easily be done in the driver flush routine.

The LTDC driver is based around the framebuffer driver. Each pixel gets set into the framebuffer. By adding a flush call to the driver GDISP will call that at appropriate moments (we will talk more on below).

For your double buffered LTDC the flush would swap the buffers and start the dma transfer. Note you would also have to put a test into the setpixel driver routine to ensure it didn't try to write a pixel before the dma transfer had finished.

Flush is the ideal place to put the double buffer swap as that is exactly what it is designed for - to take pending display updates and flush them to the real display. It is used by most of the monochrome drivers for exactly that purpose.

There are a couple of strategies that GDISP can use to call your driver flush. These are controlled by config variables. 

The default method is to call flush after each high level gdisp call. This is the best method for quick updating of the display but has the disadvantage of potentially slowing down drawing speed particularly if the flush is an expensive operation as in your case.

The alternative method is to flush on a timer. A gdisp operation triggers a timer. Thus multiple operations are merged into a single flush gaining efficiency. The period of the timer can be set to compromise between efficiency and latency.

[inmarket]

With regard to some of the other issues you raised...

With regard to ifdefs for your new code...

There are two ways of handling this, either add a config and ifdef your additional code within the existing LTDC driver. The alternative way is to create a new LTDC-db driver based on the LTDC driver. Which approach you take is your choice and probably depends on the level of complexity to the code that you are adding/changing.

With regard to passing high level synchronization flags, it is probably just not necessary. We have the flush driver interface and a gdispFlush API call that can make explicit use of it if required. Ither synchronization issues such as redraw tracing can be handled in the driver itself by yeilding to other threads or busy waiting until the retrace is available. Due to timing constraints most drivers in this situation will busy wait because the timings are too tight to allow yeilding the thread.

With regard to busting of write operations, uGFX V3 has significant advantages in this area and is one of the primary improvements in V3. Even on slow SPI links this can sometimes add efficiency because in a burst operation better choices can be made as to whether invoke dma use. Currently drivers either do or don't. If they do they are disadvantaged for short bursts, if they don't they are disadvantaged on long bursts and can't recover the cpu cycles that dma would have avoided. For V3 far more intelligent decisions can be made.

With regard to large displays with slow hardware interfaces, if you need to write the pixels then you need to write the pixels and it will take as long as it takes. While uGFX goes to a lot of trouble to avoid "double-printing" (ie unnecessary pixel drawing) particularly at the GDIP level, as they say in English "You can't make a silk purse out of a sows ear".

The one area that uGFX could improve double-printing is in the redraw strategy for GWIN. Changing this however has major considerations for other resources particularly RAM usage.

[chodzikman]

Thank you very much, by now I think I know everything to do it following your concept for the library. I didn't noticed these flush calls during my quick research.