Rewrite modm:ui:graphic

[TomSaw]

Changed some lines of the Display-API to make graphics appear faster by a factor.

PR containing the whole, latest codebase for reference: #665

Here's a little preview, running on STM32F0 @48Mhz

VID_20210713_211743.mp4

The Number is rendered into a single monochrome Buffer witch is then streamed to different displays. Only the area of the Buffer is affected. Notice the noizy bottom half of the OLEDs. The flickering squares on the ILI9341 comes from debugging code. Soo yes, just a preview ;) Details about the implementation, the benefits and more examples coming soon.

[TomSaw]

Found another promising library not yet mentioned in modms GUI-Issues nor uPainter-Docs.
It also builds up on DMA2D and the docs contain some good introduction to graphics on MCUs under Basic-Concepts

TouchGFX

[rleh]

If I remember correctly the TouchGFX license does not allow usage on non-ST devices and/or has expensive fees if used in commercial applications.

[chris-durand]

If I remember correctly the TouchGFX license does not allow usage on non-ST devices and/or has expensive fees if used in commercial applications.

It's free even for commercial applications but the license only permits use with devices manufactured by ST.

[TomSaw]

Ok, at least it's a good resource. Their explanations are very nice to read.

[TomSaw]

Finally, my Workspace 🧮 and Neurons 🧠 are ready to get known to uPainter 🎨

• I like the extra classes for geometries `class Line, class Rectangle, class Circle, class Ellipse'. Gonna migrate that too.

Questions @salkinium:

• B: What's the current solution for fixed-point-arithmetics if there's any? CMSIS?

[TomSaw]

First sub-PR for ILI9341 is out: #664
I've also PR-ed the whole code for reference #665
👉 Please correct me if there's a better practice for my situation of contributing this huge thing in chunks.

[salkinium]

What's the current solution for fixed-point-arithmetics if there's any? CMSIS?

There is none. There's a fixed point class in uPainter, however, it's a little outdated and not as flexible.
This seems to be the most promising: https://github.com/MikeLankamp/fpm

Please correct me if there's a better practice for my situation of contributing this huge thing in chunks.

Just make one big PR and partition your changes into separate commits, since we can review the changes by commits instead of by files too (see the tab Commits).

[TomSaw]

Just make one big PR and partition your changes into separate commits, since we can review the changes by commits instead of by files too (see the tab Commits).

So then all changes will be in one branch
? Makes it difficult to evolve the single changes, doesn't it?

[salkinium]

So then all changes will be in one branch? Makes it difficult to evolve the single changes, doesn't it?

Yes, you group them by commits and use fixup commits and interactive rebase to apply patches on you branch. This is a very typical git workflow and helps you break down large order-dependent changes.

You can even collaborate like this, if you carefully synchronize the rebase and force-pushes. We've done this recently for our STM32H7 work.

[TomSaw]

Okay, thanks i'm going to learn and apply this.
Please go for review of #665. I'll partition into commits later cause 'some' change requests are expected.
It's more efficient doing the partitioning to the end of the workflow !