On Sun, 05 Jan 2014 23:30:24 -0800, Joakim <joakim@airpost.net> wrote:

> On Monday, 6 January 2014 at 04:17:21 UTC, Walter Bright wrote:
>> On 1/5/2014 8:10 PM, Adam Wilson wrote:
>>> Recently, I've been working to evaluate the feasibility and reasonability of
>>> building out a binding to Cinder in D.
>>
>> For reference, here's what Cinder is:
>>
>> http://libcinder.org/
>>
>> It's been well received by the C++ community.
>
> I took a look at the website.  Other than being popular what is it about Cinder that triggered this graphics push: do they make any good technical decisions?  I can't tell just from looking at their website.

It's something that Walter and I have been discussing since the last GoingNative. A non-programmer (a sculptor by training in fact) used Cinder/C++ to create a music player app called Planetary (http://planetary.bloom.io/) for the iPad using Cinder. Walter, Andrei, and I feel that D would be a more appealing language to such creatives but D lacks the required seamlessly integrated graphics library they need to create their art. There has also been interest from a number of people for using such a library as a base for a GUI toolkit, and I am sure that their are game developers of the mobile/casual bent who would love something like this. We could probably even build in support for GPGPU work as that is closely related to graphics rendering.

Building a graphics rendering toolkit would provide the base library support for D to do quite literally anything with graphics, which is a major and growing part of computing today. It is quite essential that D have this capability.

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator

On Monday, 6 January 2014 at 07:17:05 UTC, Adam Wilson wrote:
> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
>> * Please don't make a graphics library that is useful only on PCs.
>
> That's the plan. However at this point D only works on x86 so it's a moot point. But if we built a pluggable rendering backend that would allow us to swap the rendering that should be sufficient.

I understand, but if I and others are able to achieve their goals, that's going to change soon.  It's not just about the backend, its about efficient use of resources and loose coupling.  For now, see if you can find a Pentium 166MHZ with 16MB of RAM for your testing.  If you can get it to run well there the Core-i7 users will also rejoice :-)

Of course I'm being a little silly, but please watch the following from Andei and Manu to see what I mean:
Expanding Platform Base (http://www.youtube.com/watch?v=4M-0LFBP9AU#t=2399)
Operational Professionalism (http://www.youtube.com/watch?v=4M-0LFBP9AU)
Memory Laziness (http://www.youtube.com/watch?v=FKceA691Wcg#t=2458)

>>For a quick intro, go
>> here (http://www.antigrain.com/doc/introduction/introduction.agdoc.html#toc0006).
>>  It is superior design model for anyone wishing to develop a graphics library.
>>
> I've heard of it, and we are definitely open to stealing the best of any library, so I/we take a look at it.
>
Allow me to elaborate more on why I think AGGs design is superior.  You don't actually have to port it to any platform.  Because it uses templates, the porting is done with a few typedefs at the beginning of your program like so:

typedef agg::rgba8 Color;  //could be rgb8, bgr8, rgb16, rgb32, and many others
typedef agg::span_allocator<Color> SpanAllocator;
typedef agg::span_interpolator_linear<> SpanInterpolator;
typedef agg::rendering_buffer RenderingBuffer;
typedef agg::scanline_u8 Scanline;
typedef agg::rasterizer_scanline_aa<> Rasterizer; //aa is anti-aliasing, but could be aliased if you wanted.
typedef agg::path_storage Path;
typedef agg::conv_curve<AggPath> Curve;
typedef agg::conv_stroke<AggCurve> Stroke;

This configures the entire pipeline for my platform.  I didn't need to modify any header files, set and #defines, or add a if version(MyPlatform) block to the source code, etc...  Because its template programming, these new types will be compiled when I build, and I will have a custom rendering pipeline specific to my platform.  I didn't see how elegant this was at first, but now I think it's brilliant and really fulfills the promise of template programming.

You could probably use AGG to render an uncompressed Blue-Ray movie to ASCII art if you wanted to.

I don't suggest doing the same in D, necessarily, but I do suggest understanding this pattern and let it influence the way you approach portability.  There may even be a better D way that differs substantially from this.

>>   *  The rendering engine should be its own library/package, that should be easily replaced with whatever is suitable for the given platform.
>>
>
> As in pluggable backend? That should be easy enough to do.

A pluggable backend, yes, or possibly simply specifying a different template argument.

>>> The logical phases as I can see them are as follows, but please suggest changes:
>>
>> Start with the most primitive and move up from there (If loosely coupled, the could be developed in parallel)
>> 1. Geometric primitives
>> 2. Vector graphics
>> 3. Fonts (just a special case of vector graphics)
>> 4. Rasterization
>> 5. Backend (Direct2D/3D, OpenGL, OpenVG, whatever)
>>
>
> The problem I can see here is that if you want to test the first four, number five has to be built out to some degree.

Of course you are right.  I guess I was think more "fundamentals first".

I have to say this basically has made DOOGLE obsolete however here is some things I have learnt from it:
- Separate out OpenGL implementation abstractions. E.g. Webgl vs desktop gl.
This may not be required because the aim is towards non web based output but I think something like GWT[0] would bring an interesting dimension to such a library.
Also include the opengl util stuff including textures ext. in this with having it abstracted.
- If you think your going 3d do it first, its harder (yes) but going 2d from that is pretty much load image into texture, load mapping coords and display.
- If you can explore some kind of factory mechanism, I never did but versioning implementations between sub packages was absolutely messy. Perhaps a registrations system. That works quite well for my web service framework with routes, models, update functions ext.
- From experience on Windows, the client window area is a little buggy. You may have to make up for that in making sure its exact size requested. For an idea of what I did check out[1][2]

Some ideas I had for DOOGLE but really didn't even get close to doing:
- Able to (out of process) query and manipulate the gui with a permission mechanism.
- Output html/css/js with a routing mechanism to work as a web server routes.
From what I have considered the context would need to change on request, which would hold e.g. the actual request.

[0] http://www.gwtproject.org/
[1] https://github.com/rikkimax/DOOGLE/blob/master/resources/shaders/button_popup.frag
[2] https://github.com/rikkimax/DOOGLE/blob/master/source/StandardPlatformWindow/doogle/window/opengl/window_win.d#L28

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> Hello Fellow D Heads,
> I know that the community has worked through a few of the problems involved. For example, I can't remember who wrote it, but I've seen a module floating around that can create a window in a cross-platform manner, and I know Mike Parker has been heavily involved in graphics for D.

You mean Dgame? http://dgame-dev.de/
It's still in development but the next release is coming.
I would be interested in helping. But I have only experience in OpenGL, not DirectX.

On 2014-01-06 05:10, Adam Wilson wrote:
> Hello Fellow D Heads,
>
> Recently, I've been working to evaluate the feasibility and
> reasonability of building out a binding to Cinder in D. And while it is
> certainly feasible to wrap Cinder, that a binding would be necessarily
> complex and feel very unnatural in D.
>
> So after talking it over with Walter and Andrei, we feel that, while we
> like how Cinder is designed and would very much like to have something
> like it available in D, wrapping Cinder is not the best approach in the
> long-term.
>
> With that in mind, we would like to start a discussion with interested
> parties about building a graphics library in the same concept as Cinder,
> but using an idiomatic D implementation from the ground up. Walter has
> suggested that we call it Aurora, and given the visual connotations
> associated with that name, I think it is most appropriate for this project.
>
>[SNIP]
> So with the above framework in mind, let's talk!

I like it :).

Every time I read a proposal that has anything to do with graphics I always start to think there will be problems on Mac OS X. Depending on how much interaction with the platform is needed, it always comes back to the same problem: interfacing with Objective-C. It's verbose, cumbersome and annoying to interface with Objective-C without language support. We badly need D/Objective-C [1].

[1] http://wiki.dlang.org/DIP43

-- 
/Jacob Carlborg

On 06/01/14 08:16, Adam Wilson wrote:
> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
>> * Please don't make a graphics library that is useful only on PCs.
>>
>
> That's the plan. However at this point D only works on x86 so it's a moot point.

Not really -- the GDC/LDC teams seem to be doing excellent work on ARM support which I get the feeling will arrive sooner rather than later.  I think it'll be really important to have multi-device support at the core of your graphics library project, and to factor that into your design from the beginning.

Besides, you planning in that way will give encouragement to those porting efforts :-)

Related to this: I read in the news that C++ is planning on standardizing on Cairo as a graphics library.  Is that something that could be useful to engage with?

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> If you are interested in helping with a Cinder like library for D and/or have code you'd like to contribute, let's start talking and see what happens.

First I must say I dislike the Cinder concept because C++ frameworks like this tend to have an extremely large scope (See_also: JUCE).

I work on GFM since 2012 (https://github.com/p0nce/gfm) which is 100% public domain, feel free to take anything from it. There is some overlap with Cinder's features: http://p0nce.github.io/gfm/

It seems that you want graphics API abstraction, yet Cinder has none of this.

So Cinder is basically an OpenCV competition?

Mike:

> * Break the library into loosely coupled pieces that can be used individually or aggregated by other projects to build things that we haven't even thought of
>   *  Geometric primitives should be their own library/package
>   *  Vector graphics (paths, line caps, etc...) should be their own library/package
>   *  Raster graphics should be their own library/package
>   *  Window management should be its own library/package
>   *  Font's are just data.  Don't couple them to the rendering engine.  (e.g  Convert them to a vector/raster representation and then let those libraries handle the rest.
>   *  The rendering engine should be its own library/package, that should be easily replaced with whatever is suitable for the given platform.

An independent color system module could be useful, even in Phobos.

Part of the Geometric primitives (2D/3D vectors, rotation matrices, the most commonly useful geometry algorithms and formulas) could go in a Phobos module. And the graphics library could import and use this standard module.

Something like the simpledisplay module (that the graphics library will not import) could be useful in Phobos:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

Bye,
bearophile

On 1/6/2014 6:31 PM, Namespace wrote:
> On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
>> Hello Fellow D Heads,
>> I know that the community has worked through a few of the problems
>> involved. For example, I can't remember who wrote it, but I've seen a
>> module floating around that can create a window in a cross-platform
>> manner,

> You mean Dgame? http://dgame-dev.de/

I think he's referring to simpledisplay:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d