Why are display and drawing libraries not developed separately?

Status
Not open for further replies.
C

christoph

Well-known member
I see a lot of libraries for all kinds of displays. They all include some drawing methods (pixels, lines, frames, ellipses, characters) that more or less cover the user's needs and they all include some display driver that is more or less compatible with existing other libraries.

Shouldn't it be possible to develop a flexible canvas library that taks care of the drawing, and separate display libraries that handle the I/O?

Of course, all displays are different in size, color depth, coordinate system, read access, and so on. With well-made templates, it should be possible to have drawing methods that work on a large number of displays. I'm currently working with my own code for the SSD1351, using DMA, but the drawing is done on a pretty high level and I've also come up with a set of simple widgets. Canvas code could be shared between platforms, and display drivers could be specialized for the available hardware (AVR, Cortex-M4, whatever).

Canvas and display drivers could be pre-packaged for commonly used displays to make them easier to use for beginners, and the pros could specialize them for new or less common hardware.

So, display driver writers, please join the discussion. I'm very interested in your thoughts. Such a system would also make it possible to test drawing methods on a PC with a window system, without I/O getting in the way.

Regards

Christoph
 
Adafruit use this scheme, Adafruit_GFX it's the canvas library and shared between many oled and TFT libraries from the same company. It's flexible because you can replace a particular graphic routine and maintain compatibility with other libraries, if it's well optimized it make sense.
 
You're right, they are doing it this way - so coming up with a new solution would be close to reinventing the wheel. Or would you think it's worth developing another one?
 
Adafruit_GFX has some problems, for example the text rendering it's quite slow, some basic drawing routine it's not optimized (circle), some missed (arcs). I tried some optimizations https://github.com/sumotoy/Adafruit-GFX-Library but maybe can be a good idea build from scratch another one that take advantage of the speed of Teensy, I'm thinking about antialias and matrix for 3d stuff. The good point of Adafruit_GFX is that works with almost any display, just write the I/O routines and (if it's needed) superseed some basic graphic routine like drawPixel or drawLine. Some Oled (at list SSD1632 https://github.com/sumotoy/OLED_SSD1332) has hardware accellerated basic drawing routines that created me a lot of problems with Adafruit_GFX, expecially with display rotation (that it's really useful). Now I seen some new interesting stuff that it's even more complicated but really exciting, take a look to this one:
http://www.ebay.com/itm/301021183074 it uses RA8875 Accellerator, text chip and external memory (probably also Touch) and it's pretty cheap, I don't think that standard Adafruit_GFX will be enough for this (how to use chip font? external memory? accessing accellerated drawing routines trough RA8875?) since too many function will be superseeded by new ones and because such of displays will became more popular maybe a better conceived grahic_library can be designed.
You will have all my support Christoph!
 
Last edited:
So to remain somewhat flexible for upcoming and more capable displays, such a canvas would need to know about what features the display offers, including drawing primitives, fonts, antialiasing, etc. A display that has read and write access and all required features already built-in could therefore already be a canvas, with the software layer doing nothing but issuing commands. A simulated display running on a PC for testing purposes would be an example for that. Every feature missing in the display, but required by the application, must be implemented in software. That's kinda obvious, I think.

Looking at adafruit's library, it's definitely missing some fonts. OTOH, they require different handling anyway, because they can be provided by the display, stored in RAM, Flash, or even have other sources. They can also be compressed (this is something Paul seems to be working on). What I like about adafruit's library is that they provide a way of setting the origin in any corner of the display, so it can be mounted as required. This is certainly a must. Something I'd like to add is mirroring (line or point) for cases where additional optics change the appearance of what's displayed.

Everything related to higher level graphics (widgets, primitive 3D) an be built on top of that. Shifting and rotating come to mind, or polar coordinates.

Going a level lower, the backend must provide for different buffer systems and asynchronous operation. If a display is too large for a full canvas in RAM, it must be divided into pages that are aligned with the display's native coordinate system. The ssd1351 for example draws pixels from left to right, and lines from top to bottom. Support for multiple displays would be cool, but that's probably a tough one.

Support for color spaces should include the usual suspects (monochrome, rgb16 and rgb24 at least, maybe palettes) and try to use as little RAM as possible. I'm currently doing this in my application (monochrome canvas for an rgb16 display) and it works well, using only 1/16th of the RAM for an rgb16 canvas (a bit slower, but I've got DMA to make up for that).

Anything that's missing?

Edit: I think when the canvas covers these displays in multiple color modes, we'd be close to something very flexible:
  • SSD1351 (works well with DMA, paged, monochrome canvas -> RGB16 display)
  • ILI9341 (large, good for speed benchmarks)
  • That 5" thing from ebay with a font chip you mentioned
  • That old Nokia 3310 display (RGB canvas -> monochrome display, surely odd but a good exercise for conversion algorithms)
 
Last edited:
EK701 I'm glad that you're interested, but I think your wish is slightly missing the point. Given that you don't need any special functions provided by the SSD1325, it should be easy to write a driver for it once there is a flexible system that takes care of anything not related to I/O. So by default, the SSD1325 should be simple to support.

The list I assembled above was meant to show what range of displays should (at least) be considered when writing high level software for displays in microcontroller applications. If the SSD1351 is covered, the SSD1325 is covered as well.
 
Looks promising!
A good start will be find a good way to add custom fonts without impact too much memory footprint and performance, also some new display uses internal font chip (like the 5' or new 7').
I have collected several utilities to convert font during years, some java are easy to use but font conversion it's not perfect and result in horrible looking, also maybe it's time to think to antialiased font as well as an option of course.
I did not know any font conversion utility for compressed font, btw. I will include a standard ASCII font that can be doubled or tripled as standard.
I definetively like a lot the idea oforientation and mirror option, must be a must. OK for colorspace support, I will add BGR18 because it's popular in some display, or an internal utility for conversion.
A tricky point it's the offscreen RAM handling, it's really difficult find a standard way with so many display around and all those differen resolutions and options. For example some SSD chip handle memory for 128x160 (as example) but a 128x128 it's installed and memory->screen it's not mapped to 0,0 origin but in the middle, as result many operation as orientation, fill, etc. needs offset calculations and some other function it's slowed down, I think should be a part of the display low level routines and not the graphic shared ones.
The Adafruit library for the monocrome OLED use offscreen buffer inside the library that impact a lot the memory of the controller, not a big problem for Teensy but it is with UNO or Leonardo, that's should be avoided, I was thinking a paged memory solution but should do some testing to see the performance impact.

I think nothing else missed, I've ordered the 5'' inch display today, I'm curious about the RA8875, ext memory chip and font chip, never find all 3 together in a display but this looks like the new tendency of the chinese sellers, normally those displays needs tons of lines and cannot be used with 8bit MCU but now this can change.
 
As I said the SSD1632 it's the only SSD chip I know with hardware accellerated primitive graphics, it's not so popular but have amazing performance. Unfortunatly this complicated a lot many stuff that it's easy with more standard chip like SSD1351, apart that a normal display driver will be:

1) sendCommand, sendData (optional, wait for ready in some display)
2) initialization
3) custom method for basic primitives (like drawPixel, etc.)

So used with a shared graphic library...

1) tell to Graphic Library witch dimensions, colorspace, (offscreen buffer maybe?)
2) sendCommand, sendData (optional, wait for ready in some display, almost any display has his method)
3) initialization (different to every display)
4) custom primitive methods that overridden the shared graphic ones

At this point an user should use the shared graphic routines and include the fonts he needs. The good point, in that way any display uses the same commands, really practical!
 
Last edited:
sumotoy, could we use github as a discussion tool? We could set up lists of features, sorted by topic (color spaces, display types, drawing primitives, ...), and discuss based on issues. We both already have github accounts and markdown should be sufficient for that kind of discussion from a typographic point of view. Then we can start outlining interfaces.
 
christoph said:
EK701 I'm glad that you're interested, but I think your wish is slightly missing the point. Given that you don't need any special functions provided by the SSD1325, it should be easy to write a driver for it once there is a flexible system that takes care of anything not related to I/O.
Click to expand...

Ahh, OK, I get it now.
 
Status
Not open for further replies.
Back
Top