Micropython Display Graphics Architecture and Naming Convention

[ChrisMicro]

For graphics often a layered software architecture is used like:
gui => framebuf => driver
Framebuf in Mircopython is very well documented but there are all this functions like drawing a filled rectangle are missing.
I think the naming convention of the Adafruit-GFX driver is quite good. TKinter canvas has another naming convention. Can it be normed and Is there a similar driver and naming convention for Micropython?

[peterhinch]

functions like drawing a filled rectangle are missing

FrameBuffer.rect(x, y, w, h, c[, f] From the docs:
The optional f parameter can be set to True to fill the rectangle. Otherwise just a one pixel outline is drawn.

[ChrisMicro]

Thank you for the hint. I saw your GUI-repos. What do you think of a layered architecture with compatible naming to other libraries?

[peterhinch]

OK in principle. In practice I'm not about to engage in a major application-breaking change to all my GUI modules.

[scruss]

I think the naming convention of the Adafruit-GFX driver is quite good

I was going to suggest displayio – High level, display object compositing system — Adafruit CircuitPython documentation, but it has no compatibility with GFX.

[ChrisMicro]

#The easiest to use were based on absolute positioning with a graphical screen designer as part of the IDE.

I think you are right. For small screens placing the elements manually at absolute positions seems to be a good method.

My original question is more about the API and compatibility and naming convention of the drawing functions.
I saw you made some wrappers to solve this problem here.

`
#Graphics primitives: despatch to device (i.e. framebuf) or
#local function for methods not implemented by framebuf.
#These methods support greying out color overrides.

def hline(self, x, y, l, color):
    ssd.hline(x, y, l, self._getcolor(color))

def line(self, x1, y1, x2, y2, color):
    ssd.line(x1, y1, x2, y2, self._getcolor(color))

def circle(self, x0, y0, r, color):  # Draw circle (maybe grey)
    color = self._getcolor(color)
    ssd.ellipse(int(x0), int(y0), int(r), int(r), color)`

I wonder how the wrapping are influencing the execution speed in Micropython.

[peterhinch]

It is minimal. The limiting factor in latency is the transfer time from the framebuffer to the physical display. Consider a 400x300 pixel display which requires 16-bit pixels. That is 1.92e6 bits. Even if the SPI bus runs at 60MHz that corresponds to 30ms (few displays or hosts run as fast as 60MHz so practical times are 60-80ms). Most drivers for big displays conserve RAM by using a4-bit frame buffer, so there is also some overhead in converting 4-bit color to 16-bit.

By contrast the wrappers might add an overhead of 10-20μs. In context, negligible.

[ChrisMicro]

Thank you for your answer. Would it make sense to have a framebuffer simulation running on the PC for faster development? I started a try here.

[peterhinch]

Opinions differ on this. Personally I find development on real hardware using mpremote mount is so easy that I can't see the point, but I may be in a minority here.

[corranwebster]

Thank you for your answer. Would it make sense to have a framebuffer simulation running on the PC for faster development? I started a try here.

When working on Tempe I either use an actual device as @peterhinch does or run on PC MicroPython and dump out the raw buffer bytes into a file and then convert it to .png with a simple Python Pillow script. The latter is good when you're going for close introspection of pixels as you can use regular tools, but not good for anything interactive.

[corranwebster]

Can it be normed and Is there a similar driver and naming convention for Micropython?

I think the short answer to this is 'no'. The framebuf library is deliberately small and very raster-oriented. Modern 2D drawing frameworks tend to be vector-oriented and most have APIs which are descended from DisplayPDF and similar technologies (see Apple's Quartz, Qt's QPainter, Gnome's Cairo, Windows GDL, Antigrain Geometry (AGG), etc.). You could write similar APIs that sit atop the framebuf API which mimics one of these APIs (at worst you can get and set pixels, and if you can draw polygons you can draw anything with enough extra work), but I think they'd be slow: you'd be better off writing C code that implements an API like this (this is what the folks at Pimoroni did with PicoVector.

But you're never going to get a 1-to-1 agreement with any PC drawing library unless you write both yourself.