search

pfalcon / pycopy-lib

Standard library of the Pycopy project, minimalist and light-weight Python language implementation
https://github.com/pfalcon/pycopy
Other
246 stars 70 forks source link

framebuf: unix port: buffer and format arguments are ignored #25

Open crteensy opened 5 years ago

crteensy commented 5 years ago

The unix port of FrameBuffer ignores the buffer and format arguments passed in the constructor. This makes it impossible to write drivers that need to handle or manipulate the underlying data directly.

pfalcon commented 5 years ago

The unix port of FrameBuffer ignores the buffer and format arguments passed in the constructor.

That's true, the unix port of framebuf module is a proof of concept, waiting for interested parties to develop it further.

This makes it impossible to write drivers that need to handle or manipulate the underlying data directly.

Which drivers? Which underlying data? To the best of my knowledge, the purpose of framebuf module is develop applications which draw something. You would need to elaborate how "drivers" and "underlying data" fit with this.

crteensy commented 5 years ago

About the drivers remark: I'm trying micropython mainly because I can develop an application's logic on my laptop and then - with very little effort - port it to the target (esp8266 or others, with a display connected via one of the common interfaces like SPI). Many of the common displays use smaller pixel formats, like RGB565 or even 1-bit monochrome. My current project uses a display that wants 8 monochrome pixels stored in one byte.

The documentation (https://docs.micropython.org/en/latest/library/framebuf.html) indicates that this is indeed supported, but apparently that is not true for the unix port. My hope was that the unix port would also store a frame in the same way as my target hardware so that I could also develop the code for reading the buffer data and sending it to the display on my laptop.

I hope this made my point clearer.

pfalcon commented 5 years ago

Ok, that clarifies the point. But please understand that the primary purpose of framebuffer is to draw shapes to it. And if you write an application on unix port which will draw a rectangle of size 50x50 on the framebuffer of size 128x128, then it will work the same way on esp8266, modulo the change in pixel format (define a config var for that), and perhaps "colors" used (again, config vars).

So, that's the primary purpose of unix port of framebuf. Other purposes are possible to, I'm sure interested parties will implement them.