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.

[peterhinch]

Re geometry managers I've used various PC based GUI environments - admittedly a long time ago. The easiest to use were based on absolute positioning with a graphical screen designer as part of the IDE. The best known example is Visual Basic which made screen design supremely straightforward. The IDE also introduced newbies to event-driven coding.

I'm years out of date on PC coding - I don't know if anyone has achieved an IDE like this for Python. There was something in the works with a snake-based name which eludes me but it was so buggy I reverted to TKinter.

[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.