On Sun, Jan 05, 2014 at 11:16:03PM -0800, Adam Wilson wrote:
> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
[...]
> >>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.
[...]

For initial development, it could be as simple as rendering to a generic framebuffer that then gets blitted to whatever OS primitives you have to display it on the screen. That should be enough to get things going while "real" backends get developed.


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

On Monday, 6 January 2014 at 12:57:04 UTC, Mike Parker wrote:
> I think he's referring to simpledisplay:
>
> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d


Yea, my simpledisplay.d (and its dependency, color.d) has some code for creating a window, drawing on it (including some OpenGL stuff now), getting input, and drawing on images using OS native things.

color.d has a color struct, some hsl <-> rgb functions, and a basic image framebuffer class.

Also in the repo is png.d which can load and save many png files, bmp.d for bmps, and minigui.d which builds on top of simpledisplay to add some basic gui widgets. There's also stb_truetype.d which is a port of the public domain C library for loading ttfs in a single file without a dependency on freetype or anything.

I still haven't uploaded image_basicdrawing.d because it sucks and I plagiarized one of the functions, but that thing uses the class in color.d and adds stuff like "draw line", "draw circle", etc. to it so you can draw without a backing screen.



While simpledisplay.d works reasonably well, its code is pretty ugly (half the file is just bindings to Win32 or Xlib), minigui.d is still far from complete. Most my work lately has been web UIs, so I just haven't had the push to finish it...

06-Jan-2014 19:16, H. S. Teoh пишет:
> On Sun, Jan 05, 2014 at 11:16:03PM -0800, Adam Wilson wrote:
>> On Sun, 05 Jan 2014 21:32:54 -0800, Mike <none@none.com> wrote:
> [...]
>>>> 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.
> [...]
>
> For initial development, it could be as simple as rendering to a generic
> framebuffer that then gets blitted to whatever OS primitives you have to
> display it on the screen. That should be enough to get things going
> while "real" backends get developed.

It would be better not to or you risk introducing suboptimal software rendering patterns that do not have even remote correspondence to the hardware.


-- 
Dmitry Olshansky

On Monday, 6 January 2014 at 12:52:02 UTC, bearophile wrote:
> An independent color system module could be useful, even in Phobos.

Did you see my color.d that simpledisplay now depends on? It isn't particularly fancy, but I found that having an independent color struct was useful since it is imported by many modules, and moving it out to its own kept them from getting too inter-dependent. I put the basic image framebuffer there for the same reason - it is very little code, but having a reusable common type with easy access helps interoperability.

On Monday, 6 January 2014 at 04:11:07 UTC, Adam Wilson wrote:
> The logical phases as I can see them are as follows, but please suggest changes:
>
> - Windowing and System Interaction (Including Keyboard/Mouse/Touch Input)
> - Basic Drawing (2D Shapes, Lines, Gradients, etc)
> - Image Rendering (Image Loading, Rendering, Modification, Saving, etc.)
> - 3D Drawing (By far the most complex stage, so we'll leave it for last)

I suggest you start working the other way. Because if you want performance you will most likely want everything in the render path to be based on shaders:

1. Fonts and monochrome icons based on distance-fields.
2. All fills based on shaders, with the ability to convert D into GLSL etc.
3. Render to texture, with caching mechanism.
4. Simplistic mesh rendering from native D arrays.
5. The ability to attach native 3D code paths (GL/DX) to the engine for advanced meshes.

Then you build 2D on top of this.

Rendering and input should be completely separate.

On Sun, 05 Jan 2014 20:10:06 -0800, 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.

I've been writing graphical applications using D and OpenGL on Linux for a few years now in my spare time, so I'd like to help out.  Just last week I googled "alternatives to Cinder" looking a library that had C bindings so that I could use it from D.

> 
> The logical phases as I can see them are as follows, but please suggest changes:
> 
> - Windowing and System Interaction (Including Keyboard/Mouse/Touch
> Input) - Basic Drawing (2D Shapes, Lines, Gradients, etc)
> - Image Rendering (Image Loading, Rendering, Modification, Saving, etc.)
> - 3D Drawing (By far the most complex stage, so we'll leave it for last)

If the ultimate goal is a high-level, idiomatic D library for people who are not necessarily experienced in CG, then shouldn't we start with the high-level interface and work down?  That way the end-result drives the design and not the other way around.  I understand that to be accepted into Phobos someday this library will need a minimal set of system dependencies, but in the short term it may be wise to simply wrap existing libraries like GLFW3 for low-level systems like windowing.  In my experience, successful products deliver the vision to the customers as quickly as possible, allowing the design to be refined.  Replacing low- level components with native D implementations should be invisible to the end-users anyways, making them the most non-essential.

I'd also second the suggestion to build everything on top of OpenGL and DirectX--virtually every device that has an interactive display these days has hardware acceleration in some form.

I'm not familiar with Cinder library yet (seems it does not support Linux, so it's not very interesting for me), but I suppose graphics library should provide at least two approaches to build graphic applications. The first one is something that SDL and SFML offer: user has to manually write cycle loop for event handling. The second one is more complicated: event loop is encapsulated by some Application class which automatically dispatches events to gui elements and provide signal-slot system to ease creation of application logic (like Qt library does). The second approach implementation may be built on the first one, but it should not be the only. Sometimes the first approach is more easy and it has no overhead of all these high-level gui abstractions.

On Monday, 6 January 2014 at 16:52:50 UTC, Justin Whear wrote:
> If the ultimate goal is a high-level, idiomatic D library for people who
> are not necessarily experienced in CG, then shouldn't we start with the
> high-level interface and work down?  That way the end-result

I don't disagree with this, but in reality most graphical applications are simpler if you decouple the world-model from the visuals and hence input from output and generate the visuals from scratch for every frame. Cocos2D is a popular library that maintains graphical state for you, but if you want to decouple the model from rendering you end up syncing two data structures which in the end is more work.

I think most successful libraries are focused and do one thing really well, so suggesting dependencies:

CG BASIC
- vec: SSE tuples with swizzle
- geom2 depends on vec: basic geometry
- geom3 depends on vec (and geom2): 3D geometry
- spatialcollections depends on geom3: acceleration data structures

GPU
- gpu depends on vec: DX/GL abstraction with shader support
- textureloader depends on gpu: loading jpeg/png into gpu memory with caching
- texturerender depends on gpu, geom2,svgpath,image loader: render to texture

VG
- svgpath depends on geom2: implements all svg path primitives + transformations
- fontreader depends on geom2, svgpath: reading font+metadata + generating paths
- fieldfont depends on fontreader, svgpath: creates signed distance field textures
- simplepostscript depends on svgpath: for building pdf/drawing on canvas2D

OS
- input: cross platform solution for input for various devices (might look at marmalade and other cross platform engines for ideas)

SAMPLE ENGINES
- canvas3D depends on canvas2D, geom3, spatialcollections, texturerender/loader,input
- canvas2D... etc

Another lib to consider is www.cairographics.org
Herb Sutter wants to base the 2d stuff of c++ on it
http://lists.cairographics.org/archives/cairo/2013-December/024858.html

On Monday, 6 January 2014 at 18:34:53 UTC, Keesjan wrote:
> Another lib to consider is www.cairographics.org

I think Cairo only support straight lines and cubic bezier curves in what appears to be a somewhat inefficient format, but the backend support is quite extensive.