Graphics Library for D

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Wed Jan 8 00:58:54 PST 2014


On Wednesday, 8 January 2014 at 02:38:11 UTC, Mike Parker wrote:
> It is very much possible. There are a number of high-level 
> graphics APIs out there designed in just such a way, many of 
> which predate shader APIs. Java2D is a prominent one.

Java2D is a Display Postscript wannabe.
Direct2D is a Display Postscript wannabe.
Quartz is a Display Postscript wannabe.
Cairo is a Display Postscript wannabe.

If you want a Display Postscript API. Then say so.

However, these implementations are probably incompatible when it 
comes to the lower level compositor, what level of access you 
have to the compositor and so on. So NO! You cannot just make a 
high level design without favouring one platform over another. 
You have to either ANALYZE all platforms and find a subset that 
performs well across the board OR pick a solution that is cross 
platform, like Cairo.

You do not want inconsistent performance across platforms for an 
interactive API, that makes porting software time consuming and 
expensive.

SVG is the better choice though because it is a retained mode API 
that actually is a standard and it hides the compositor.

> For the sort of package we're discussing here, you should never 
> define the high-level API in terms of low-level API features. 
> Shaders shouldn't even enter into the equation. That's the sort 
> of backend implementation detail that users of the API 
> shouldn't have to worry about.

If you want access to the compositor you certainly will have to!

> model your API more closely to the hardware. But for a 
> general-purpose graphics API that needs to be available on as 
> many devices as possible, that's not going to work.

Blindly inventing your own Display Postscript and Compositor is 
most certainly going to make it non-interactive/not-implemented 
on a wide array of devices.

> It's quite possible to put together a reasonably performant, 
> easy-to-use, general purpose graphics API that can take 
> advantage of the best renderer on a given platform without 
> letting the low-level details leak into the high-level design.

No, it is most certainly not possible to come up with a PORTABLE 
design for INTERACTIVE graphics without taking the lower level 
layer into consideration.

That will only work if you implement your own scanline-renderer. 
Which is slow.


More information about the Digitalmars-d mailing list