Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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.
Graphics/font/platform backends with common interfaces?
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
}
Re: Graphics/font/platform backends with common interfaces?
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?
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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?
Re: Graphics/font/platform backends with common interfaces?
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?
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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?
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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.w9w0efr1707...@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?
Re: Graphics/font/platform backends with common interfaces?
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.w9w0efr1707...@invictus.hra.local
Source Code: https://github.com/auroragraphics/
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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.
Re: Graphics/font/platform backends with common interfaces?
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 | +-+
Re: Graphics/font/platform backends with common interfaces?
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.
