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.

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.

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?

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.

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.

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.

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.

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.