Pure Python Framebuf Module

[hoihu]

I thought the framebuf module could be translated into "pure-python" using the micropython optimizations @viper and @asm_thumb for ARM (Ok - asm_thumb is no more that "python-style" ;) )

The advantage would be that it could be easily extended. For example, if a separate color format is needed - without recompilation.

But how fast could that be, compared to C-code?

I let Claude do some work and put the results in my repo. It's been a bit of a rollercoaster to do that, but over all I'm pretty surprised how Claude was able to do it. I've put some details about this process in the repo.

It's still early days, I did not test this yet in a real project. Still, it gives a clue how fast it could be. TLDR; in some cases it's faster, in most cases 2-3 times slower.

I'm considering to use this as a base for my own implementation of RGB888 color modes etc. I thought maybe somebody else is interested in similar things, that's why I posted it here.

[shariltumin]

Good job! I will definitely try your library when the occasion arises.

AI, especially agentic AI, is a powerful tool. In the right hands, they can produce wonders.

What should we call our field now? Idea engineering? Idea science?

I just hope it won't take away my joy of programming.

[hoihu]

I just hope it won't take away my joy of programming.

Yeah, it's a two sided sword somehow.

On one hand, very powerful and it lets you explore ideas very quickly.

On the other hand, you'll loose the "touch" to the codebase. The iterative way of programming and fine-tuning is now done by the model (somewhat... ).

I'm also fearing that in the long run, we're loosing the ability to quickly sketch code for ourselves and "outsource" this completely to the model.

It'll be interesting to see how things evolve...

[peterhinch]

Impressive! To fully replace the C module there should be line, poly, ellipse, text, scroll and blit methods. Another limitation is the use of asm, which loses the cross-platform nature of the built-in module. However the speed gain for monochrome modes is remarkable!

A simpler, cross-platform approach to handling unsupported modes is with on-the-fly mapping. Here the framebuffer contents are mapped prior to being transferred to the display. This has been used to support hardware that requires RGB666, e.g. the ILI9488 chip. There is an inevitable speed penalty, but using Viper this can be kept acceptably small. This type of on-the-fly mapping can also enable a 4-bit framebuf to support a limited set of 16-bit colors via a LUT. This saves RAM at some cost in speed. See nano-gui for examples of this technique.

[hoihu]

Hi Peter,

I completely forgot to mention that the implementation is not complete! Thanks for pointing that out.
(... Claude is chewing on this right now... )

A simpler, cross-platform approach to handling unsupported modes is with on-the-fly mapping

Definitely - btw I did a similar thing for my little project I'm working on which uses an LED matrix and shift registers. I also did this mapping with viper ;) so that worked also nicely.

I was just very curious how a custom made, python based framebuf module would perform.

In some cases it's beneficial if the byte array has a certain structure, so that it can be easily DMA'd out to the display, in the background. That's really nice to have in case you need to refresh the display continuously (e.g. for PWM dimming etc).

[peterhinch]

Hi Martin,
I experimented with background refresh using two approaches. Firstly running the refresh task on the second core of RP2 and secondly writing an asynchronous SPI master using the PIO. While both of these worked, there was minimal difference to the responsiveness of the GUI. I did not pursue these single-platform solutions.

I will experiment with your implementation when it's more complete, but my GUIs use the line, poly, ellipse and blit methods. I would expect it to work fine as the main determinant of latency is the transfer time over SPI which should be unchanged.