It's the exams phase so I don't have a detailed review, but here are some rought points:

• Overall: Yes, very nice!
• Don't put an endianess template parameter in the color format, especially if you don't even store the underlying data in said endian format. Instead use modm::toBigEndian/modm::fromBigEndian inside the buffer functions.
• I'm unsure about the Resumable interface. I see the issue with the SPI transfers for the off-device frame buffer of the Ili9341, however there's a lot of duplication with RF_CALL stuff, that would fall away when we switch to fibers.
• Not sure why the Buffer needs to know the type of the Painter? I think the buffer should only abstract the resolution/data format/pixel access and the Painter should access that via a virtual interface (which may include optimizations like your fast methods).
• The .font files and the SConscript.generate can be deleted as they are duplicated in modm/tools/font_creator/fonts, however, the ubuntu_36.font should be copied there. Perhaps in future we could replace the modm/tools/font_creator with something better.

Thanks @salkinium for the quick review. I'm happy with such short mentoring, Nice to hear the code isn't bullshit and thanks for the feedback.

... especially if you don't even store the underlying data in said endian format

It pays out to handle the Color in delivery format from minute one. The Endian feature in Rgb565 is not yet completely implemented but I do store it in said format and works as expected. Another optimal solution arised - no more need to adjust endianes. See my latest comments in #666.

Buffer needs to know the type of the Painter?

Painter manipulates Buffer / Display only via one of drawFast(...) because the memory-mappings of monochrome Buffer / colored Buffer / Display work so differently. I don't wanted a composition-coupling via pointer between Painter and Buffer. For max. speed, Painter needs to be a Base to Buffer / Display with virtual drawFast(...) methods.
EDIT: Took me a while to see 🧐 I had to swap the inheritance 🤓:

Before: Buffer/Display-> Painter, Now: Painter->Buffer / Display

Advantages

• Inline instead of virtual calls of drawFast(..) makes drawing ~1-20% faster
• Template declarations of Buffer<...> and it's methods simplified
• RemotePainter->Ili9341 now works with Resumable Functions! Hurray

The declarations of LocalPainter / RemotePainter are ugly for now. Working on this...

I'm generally positively impressed by these changes and looking forward to the finished PR, particularly since there are many very cool improvements in here! 😍

However, I've completely lost the overview of this PR and GitHub is struggling to show me the whole diff, due to +6,742 −14,976 changes, so I'm struggling to review it… There are also too many commits for me to click through, so I cannot review commit by commit either.

I think we need to split this up a little, are there changes you can pull out into separate PRs that are more independent? There's no time pressure, just want to let you know that I'm willing to review just not really able to.

Quote @salkinium, 30 .Juli 2021 in #660 😜

Just make one big PR and partition your changes into separate commits

Also didn't expect such a code explosion - It's much fun, a great learning subject and ongoing story: Let's keep #665 as reference and merge proven pieces step bz step! Here's Nr.1 #690

are there changes you can pull out into separate PRs that are more independent

Yes. I have renamed the ordered list in my opening message: Planned commits -> Planned PRs.

I've created PRs for environmental changes @salkinium so we get the table as clean as possible to concentrate on the real chunks. See section Roadmap in this PRs opening message.

I think we need to split this up a little, are there changes you can pull out into separate PRs that are more independent? There's no time pressure, just want to let you know that I'm willing to review just not really able to.

Closed because PR is way too big. First fragments are in review and you find the rest of the code in my origin feature/rewrite-graphic