Is there a standardised way of adding graphics support to a port?

[davidgiven]

The board I'm doing a port for has a screen. I'd like to support this.

I don't see any other ports with anything that looks obviously like a graphics library, but I do see a bewildering array of external libraries which do this. Is the intention that graphics is out-of-scope for the port?

The reason I ask is that I have some particular requirements: I'm on a device with extremely limited RAM but has lots of flash, and so need something which doesn't have a local framebuffer, has the bulk of the code in C, etc. In this situation, is it appropriate to embed the library into the port, or does this belong as an external driver? If the former, is there any particular API I should be following?

Thanks!

[rkompass]

Two related options come into mind:

1. Use the abilities of the framebuf module, but set it up so that you have a list of your graphical primitives and render them on a framebuffer representing only a part of the screen. This part may then be written out to the display and the same graphical primitive list may be rendered on the framebuffer this time representing the next part of the screen. And so on, cycling through all screen parts.
   Caveat: Some primitives like polygons might not be renderable this way as they might rely on having all corners in the same buffer.
2. Try to use lvgl (and lvgl,) which does exactly this but without the framebuffer module and with it's own C code.
   If you have the 16k RAM board this may not work, however. They claim to need 32k RAM. I don't know how far this demand might be reduced. They plan to have a 1-byte per pixel color mode, but this is not there yet, for example. Currently they use at least 2 bytes per pixel. The rendering should take a buffer of recommended size of at least 1/10 of the screen, but it's configurable. Perhaps you may set it to much less...

[davidgiven]

Thanks, but as I have about 10kB of free RAM after system overheads, having any kind of framebuffer at all won't work! I forgot to say that my screen is a standard ST7735 connected via SPI, with its own internal framebuffer, so a local framebuffer isn't needed, Adafruit_GFX-style. (Which I can't use, because I don't have a C++ compiler.)

I suppose copying modframebuf.c and modifying it to work via SPI is feasible, but that feels like it's reinventing the wheel.

[rkompass]

Calculating: 160 * 128 = 20480. 20480 / 10 = 2048. 2048 * 2 = 4096.
Depends on how much RAM overhead the lvgl needs.

[andrewleech]

The standard way of using framebuf is to have the full screen worth buffered, so this only really works on devices with a lot of ram.

Lvgl on the other hand is designed to only have a very small portion buffered at any time which is used to assemble your display widgets etc. So it would possibly work in this case, though I'm not sure just how little ram it can effectively work with.

There's no real standard way to integrate lvgl currently however, though there's a few people working on it at the moment so watch this space.