Graphics/font/platform backends with common interfaces?

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist 
wrote:
> Shouldn't there be like a common (interface/abstract class) 
> that these back-ends can fulfill? maybe I am unaware of how 
> these things are done. And perhaps there are performance 
> reasons that many of these are baked in.

The way I see it it can be decomposed in many parts.

{color definition} depends on nothing
{image concept library} depends on {color definition}
{windowing library} depends on {image concept library} and 
platform APIs
{image loading library} depends on {image concept library}
{software rasterizer} depends on {image loading library}
{font rasterizer} depends on {image loading library}
{UI libray} depends on {windowing library}, {font rasterizer} and 
{image loading library} and probably everything else.

To simplify I think only UI libraries and windowing libraries 
need to know about GPU acceleration.

For example ae.utils.graphics is an amazing image concept library 
(also color definition) we have.
imageformats is a good loader library that define its own 
abstraction.
for font rasterizer I use a translation of stb_truetype but 
something way better could be done that looses less generality.

I think we need a more STL-like approach to UI but it seems not 
enough people are willing to reuse each other work and avoid 
creating new interfaces/data types, in favor of creating full 
stack solutions.