www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Graphics/font/platform backends with common interfaces?

reply Taylor Hillegeist <taylorh140 gmail.com> writes:
So I have seen alot of projects that need the same sort of stuff.

graphics libraries
gui libraries
game libraries
ploting libaries

they would all benefit from a backend solution with a common 
interface for

color
fonts
drawing pen_style aliasing etc.

but each one i look at seems to have a built up solution with 
various degrees of integration with things like freetype gdi 
cairo sdl glew opengl.

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.

perhaps it should be like:

standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.

//probably a grotesque simplification

interface font_do{
   glyphstrokes getstrokes(string characterstoget);
}

interface draw_do{
   drawpixel(double x,double y);
   drawline(double x,double y);
   drawglyph(glypstrokes g);
   getpostdrawnsize(glypstroks g)
   ... other things
}
Dec 23 2015
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist 
wrote:

 So I have seen alot of projects that need the same sort of 
 stuff.

 graphics libraries
 gui libraries
 game libraries
 ploting libaries

 they would all benefit from a backend solution with a common 
 interface for

 color
 fonts
 drawing pen_style aliasing etc.

 but each one i look at seems to have a built up solution with 
 various degrees of integration with things like freetype gdi 
 cairo sdl glew opengl.

 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.

 perhaps it should be like:

 standard color implementation.
 font interface that converts glyphs into drawing strokes.
 and a standard set of drawing instructions with transforms.

 //probably a grotesque simplification

 interface font_do{
   glyphstrokes getstrokes(string characterstoget);
 }

 interface draw_do{
   drawpixel(double x,double y);
   drawline(double x,double y);
   drawglyph(glypstrokes g);
   getpostdrawnsize(glypstroks g)
   ... other things
 }


It was an initiative, but it looks abandoned now (Aurora 
Graphics):
Thread: 
http://forum.dlang.org/thread/op.w9w0efr1707hn8 invictus.hra.local
Source Code: https://github.com/auroragraphics/
Dec 23 2015
parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 20:23:25 UTC, rumbu wrote:

 On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor

 It was an initiative, but it looks abandoned now (Aurora 
 Graphics):
 Thread: 
 http://forum.dlang.org/thread/op.w9w0efr1707hn8 invictus.hra.local
 Source Code: https://github.com/auroragraphics/


I know I was excited when It was announced at DConf 2014. It 
really is too bad.

what can be done now? how are standards defined around here for 
the benefit of the community?

+---------------+
|   USER APP    |
+---------------+
|   GUI LIB     |
+---------------+ <----- what is this interface
|  GRAPICS LIB  |
+---+---+-------+ <----- what is this interface
|SDL|GDI|OPENGL.|
+---+---+-------+

But is there any standard interfaces?
Dec 23 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist 
wrote:

 |  GRAPICS LIB  |
 +---+---+-------+ <----- what is this interface
 |SDL|GDI|OPENGL.|
 +---+---+-------+


SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly 
to put an interface there.
Dec 23 2015
next sibling parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
 Hillegeist wrote:

 |  GRAPICS LIB  |
 +---+---+-------+ <----- what is this interface
 |SDL|GDI|OPENGL.|
 +---+---+-------+


 SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
 silly to put an interface there.


I guess I'm thinking that to be able to switch between 
backends(gdi sdl) you use you must have a common interface. And 
if everyone had the same common interface it could be nice right?
Dec 23 2015
parent Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 20:57:27 UTC, Taylor Hillegeist 
wrote:

 On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
 wrote:

 On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
 Hillegeist wrote:

 |  GRAPICS LIB  |
 +---+---+-------+ <----- what is this interface
 |SDL|GDI|OPENGL.|
 +---+---+-------+


 SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
 silly to put an interface there.


 I guess I'm thinking that to be able to switch between 
 backends(gdi sdl) you use you must have a common interface. And 
 if everyone had the same common interface it could be nice 
 right?


maybe this is more what I'm thinking.

  +-----------------+
  |     USER APP    |
  +-----------------+
  |     GUI LIB     |
  +-----------------+ <----- what is this interface
  |    GenericGL    |
  +-----------------+ <----- what is this interface
  |    NativeGL     |
  +-----------------+
Dec 23 2015
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
 Hillegeist wrote:

 |  GRAPICS LIB  |
 +---+---+-------+ <----- what is this interface
 |SDL|GDI|OPENGL.|
 +---+---+-------+


 SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
 silly to put an interface there.


yes silly, more specially as

- some of them are 2D with FP coordinates
- some of them are 2D with integral coordinates
- some of them are 2D with integral coordinates with 
transformation of the plan
- some of them are 2D with integral coordinates without 
transformation of the plan
- some of them are 3D FP float coordinates with transformation of 
the plan
- some of them are in DirectMode, some of them not.
- etc...

So this would result in 5 or 6 templatized (because of the coord 
type) interface.
IIRC Interfaces are not devirtualizables so that they can be 
extracted...

also to put SDL and OPENGL on the same level is a bit strange.
Dec 23 2015
parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:

 On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
 wrote:

 [...]


 yes silly, more specially as

 - some of them are 2D with FP coordinates
 - some of them are 2D with integral coordinates
 - some of them are 2D with integral coordinates with 
 transformation of the plan
 - some of them are 2D with integral coordinates without 
 transformation of the plan
 - some of them are 3D FP float coordinates with transformation 
 of the plan
 - some of them are in DirectMode, some of them not.
 - etc...

 So this would result in 5 or 6 templatized (because of the 
 coord type) interface.
 IIRC Interfaces are not devirtualizables so that they can be 
 extracted...

 also to put SDL and OPENGL on the same level is a bit strange.


Thanks for letting me know! So is what your saying is that an 
common interface is not possible or practical or perhaps useful?
Dec 23 2015
next sibling parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist 
wrote:

 On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:

 [...]


 Thanks for letting me know! So is what your saying is that an 
 common interface is not possible or practical or perhaps useful?


Also wouldn't the least common denominator be
2D FP in Retained Mode?
Dec 23 2015
parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 23 December 2015 at 21:19:14 UTC, Taylor Hillegeist 
wrote:

 On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor 
 Hillegeist wrote:

 On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. 
 wrote:

 [...]


 Thanks for letting me know! So is what your saying is that an 
 common interface is not possible or practical or perhaps 
 useful?


 Also wouldn't the least common denominator be
 2D FP in Retained Mode?


Yes. and 2D FP immediate the most common then. GDI+, cairo, OGL 
ok. GDI with a lot of rouding.
Dec 23 2015
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist 
wrote:

 On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:

 [...]


 Thanks for letting me know! So is what your saying is that an 
 common interface is not possible or practical or perhaps useful?


It's possible but it seems to be complex.
Dec 23 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

 So I have seen alot of projects that need the same sort of stuff.

 graphics libraries
 gui libraries
 game libraries
 ploting libaries

 they would all benefit from a backend solution with a common interface for

 color
 fonts
 drawing pen_style aliasing etc.

 but each one i look at seems to have a built up solution with various
 degrees of integration with things like freetype gdi cairo sdl glew opengl.

 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.

 perhaps it should be like:

 standard color implementation.
 font interface that converts glyphs into drawing strokes.
 and a standard set of drawing instructions with transforms.

 //probably a grotesque simplification

 interface font_do{
    glyphstrokes getstrokes(string characterstoget);
 }

 interface draw_do{
    drawpixel(double x,double y);
    drawline(double x,double y);
    drawglyph(glypstrokes g);
    getpostdrawnsize(glypstroks g)
    ... other things
 }


So far I've been implementing windowing and image libraries for Phobos.
Right now windowing works on Windows minice eventing. Once eventing is 
done it is ready for the first stage of feedback.

Image library is nearly ready for next batch of feedback, PNG 
read/writer is ugh not passing its tests for palette + Adam7 interlacing.

All in all looking at second half of next year for completion.

Manu Evans has been working on the color library which I use.
The vertices definition I am using is from gfm:math with permission for 
Phobos inclusion but that needs drastic changes and somebody to take 
ownership of.

Of course that really doesn't help when it comes to e.g. font 
rasterization. But they are core and must be working first.
Dec 23 2015
next sibling parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole 
wrote:

 On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

 [...]


 So far I've been implementing windowing and image libraries for 
 Phobos.
 Right now windowing works on Windows minice eventing. Once 
 eventing is done it is ready for the first stage of feedback.

 [...]


How do you handle fonts?
Dec 23 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 24/12/15 4:03 PM, Taylor Hillegeist wrote:

 On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote:

 On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

 [...]


 So far I've been implementing windowing and image libraries for Phobos.
 Right now windowing works on Windows minice eventing. Once eventing is
 done it is ready for the first stage of feedback.

 [...]


 How do you handle fonts?


Once my existing backlog is complete I /may/ consider a font rasterizer.
Dec 23 2015
prev sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole 
wrote:


 So far I've been implementing windowing and image libraries for 
 Phobos.
 Right now windowing works on Windows minice eventing. Once 
 eventing is done it is ready for the first stage of feedback.


I don't understand something about this project. Having existing 
GtkD, DFL, DlangUI, SimpleDisplay, DQuick and probably a few 
others, creating windows on different platforms and eventing 
seems to be a solved problem, multiple times solved. But your 
project is lasting for years at this little stage. And this makes 
me wonder what it is about.
Dec 25 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/12/15 3:46 AM, thedeemon wrote:

 On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote:


 So far I've been implementing windowing and image libraries for Phobos.
 Right now windowing works on Windows minice eventing. Once eventing is
 done it is ready for the first stage of feedback.


 I don't understand something about this project. Having existing GtkD,
 DFL, DlangUI, SimpleDisplay, DQuick and probably a few others, creating
 windows on different platforms and eventing seems to be a solved
 problem, multiple times solved. But your project is lasting for years at
 this little stage. And this makes me wonder what it is about.


I take a lot longer because I'm not doing the quick and dirty.
In a few hundred lines you can on Windows for example create a window 
and OpenGL context. Great!

But now what about iterating over the displays? Screenshots?
Changing title? Icons? Notifications?

This is why it is not a solved problem.


I've just checked SDL, it doesn't handle notifications at all and a 
bunch of other things I do.

I'm almost ready for a feedback post. Problem is.. png image loader is 
failing on palette interlaced loading.
Dec 25 2015
prev sibling next sibling parent Vadim Lopatin <coolreader.org gmail.com> writes:
On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist 
wrote:

 So I have seen alot of projects that need the same sort of 
 stuff.

 graphics libraries
 gui libraries
 game libraries
 ploting libaries

 they would all benefit from a backend solution with a common 
 interface for

 color
 fonts
 drawing pen_style aliasing etc.

 but each one i look at seems to have a built up solution with 
 various degrees of integration with things like freetype gdi 
 cairo sdl glew opengl.

 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.

 perhaps it should be like:

 standard color implementation.
 font interface that converts glyphs into drawing strokes.
 and a standard set of drawing instructions with transforms.

 //probably a grotesque simplification

 interface font_do{
   glyphstrokes getstrokes(string characterstoget);
 }

 interface draw_do{
   drawpixel(double x,double y);
   drawline(double x,double y);
   drawglyph(glypstrokes g);
   getpostdrawnsize(glypstroks g)
   ... other things
 }


I can consider splitting of DlangUI library into platform and 
widgets.
Platform will provide window creation, initialization of OpenGL 
context when necessary, keyboard and mouse events, user events. 
As well, it has font support - FreeType and on Windows it can use 
native Windows fonts.

Currently supported platforms:
Windows: Win32 API or SDL
Linux, OSX: SDL or X11
I'm planning to make Cocoa (native OSX) and Wayland (for Linux) 
support later.
Dec 25 2015
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
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.
Dec 25 2015