adafruit / Adafruit-GFX-Library

Adafruit GFX graphics core Arduino library, this is the 'core' class that all our other graphics libraries derive from
https://learn.adafruit.com/adafruit-gfx-graphics-library
Other
2.36k stars 1.53k forks source link

abstract capabilities & 24 Bit RGB interface #128

Open pljakobs opened 7 years ago

pljakobs commented 7 years ago

So I'm working on this library that should be able to just position gauges on any kind of display. While doing that, it appears to me that, depending on the implementation of the underlying display class, the api of Adafruit_GFX differs and / or capabilities cannot be exposed since they are not in the base calls (one key point being the 16 Bit RGB565 interface that doesn't allow better color rendition). I wonder what could be done to enhance the compatibility between the different displays and better abstract code from the actual implementation of the display itself. First point would be a function that returns the capabilities for a given display like so:

#define GFXCAP_BW 1
#define GFXCAP_GS 2
#define GFXCAP_RGB12 3
#define GFXCAP_RGB15 4
#define GFXCAP_RGB565 5
#define GFXCAP_DIM 16

uint32_t Adafruit_GFX::getCapabilities(){
    /* 
     * default reports to be a "standard" 16Bit RGB565 color model for compatibility
     * graphics device classes should implement their own function to report more
     * appropriate values and allow for color depth management
     */
    return 1<<GFXCAP_RGB565 ;
}

This would have to be implemented by every single display so that the code using it can know what it's dealing with (in conjunction with the width() and height() calls) and, for example, allocate the correct bit depth of canvas if needed.

Additionally, a 24 Bit RGB interface is needed. The functions for that as implemented in Adafruit_GFX itself could just call their 16 Bit equivalents by reducing the 24 Bit color to 16 Bit and issuing the corresponding call, thus maintaining compatibility with existing display libraries but allowing the 24 Bit interface to be used at the application level.

Hardware dependent implementations should implement their own versions of this 24 Bit interface and do their own color mapping if required.

Time permitting, I'll try to submit a patch for Adafruit_GFX that implements the 24 Bit interface and maintains compatibility, but I would like to solicit feedback before I go all out on this.

I have started a branch here https://github.com/pljakobs/Adafruit-GFX-Library/tree/Feature-rgb24

pljakobs commented 6 years ago

@ladyada @PaintYourDragon so I'm slowly continuing to work on a few extensions to the GFX library. Currently, I have thefirst working prototype for a bitplane approach to memory saving canvasses. (see https://github.com/pljakobs/Adafruit-GFX-Library/tree/Feature-bitplanes) This also implements a 24 Bit color model to be able to set the canvas palette to rgb24 colors. Further up here, I have suggested an extension to the device drivers with this abstract capability model (and ideally, subsequently extending the driver's interface to handle those extended capabilities). I do understand that you want to keep Adafruit-GFX stable as is and also not bloat the code size - what would the best way forward be for an extended grafics infrastructure? An extended branch under the main project, clearly marked as potentially not compatible (although, so far, I have not introduced any incompatibility) or a full featured fork? If there is interest, I would be willing to maintain a fork and see where this develops. Is there a forum where Ideas could be discussed? Were a team around a future version could come together? There are a number of PRs on the main repo that have never been included, how would those move over to a fork?

pj