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.
