Dear D community

Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.

The API is designed to support third-party implementations for cases when the default (software) implementation does not fit the bill. These additional implementations are free to accelerate both the buffering and the rendering, and an OpenGL wrapper will likely be provided for those systems with OpenGL support. All implementations will support headless systems.

Contact:
http://www.dsource.org/projects/tango/wiki/Contact

Signed,

The Tango Team

http://www.dsource.org/projects/tango/wiki/Contributors

----

Tango is a cohesive runtime and library for the D programming language. A feature list can be found on http://www.dsource.org/projects/tango/wiki/Features

Mike Parker wrote:

> Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.

This all sounds very useful, but I have to ask why this is being added to Tango. The structure of Tango as a monolithic package only makes sense (to me) for heavily interdependent components. I can't see many other modules in Tango being dependent on this library, so why does its release schedule need to be tied to Tango's?

I found nothing written about the design of this library in the posted links (I probably didn't look hard enough). Is the idea to do everything Cairo, OpenVG, Java2D, GDI+, Quartz, etc can do?

What are the target applications? When reading the above, I got something such as web server graphics generation in mind. Is the library meant to support things ranging from accelerated 2D graphics for games to high quality desktop publishing technologies such as advanced type setting?

What back ends are developed? Apart from a basic image buffer back end (I assume), what other back ends are being considered primary? SVG, PostScript, PDF, GDI+ and OpenGL all seem to be candidates.

What external libraries will this depend on? I assume libpng and FreeType at the very least.

In all, it sound very interesting. I have personally several applications that could use this. There must have been a tremendous amount of work involved getting this done.

-- 
Oskar

Oskar Linde wrote:
> Mike Parker wrote:
> 
>> Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.
> 
> This all sounds very useful, but I have to ask why this is being added to Tango. The structure of Tango as a monolithic package only makes sense (to me) for heavily interdependent components. I can't see many other modules in Tango being dependent on this library, so why does its release schedule need to be tied to Tango's?

The impetus behind the idea was server-side image generation. It will complement Tango's sever-oriented packages nicely.

> 
> I found nothing written about the design of this library in the posted links (I probably didn't look hard enough). Is the idea to do everything Cairo, OpenVG, Java2D, GDI+, Quartz, etc can do?

Nothing has been published just yet. It's going to be a while before it is integrated into the Tango core. You'll be able much of what those libraries allow you to, if not everything. The basic feature list is fixed to that I listed in the announcement above. More advanced features are being considered.

> 
> What are the target applications? When reading the above, I got something such as web server graphics generation in mind. Is the library meant to support things ranging from accelerated 2D graphics for games to high quality desktop publishing technologies such as advanced type setting?

The number one goal is server-side image generation in a headless environment and the package is being designed with that in mind. Usability and extensibility are being given priority to performance. While we do want it to be able to generate images quickly on-the-fly, I wouldn't recommend it for game development. It is designed to work on buffers independent of any GUI or graphics system, not really something games would find beneficial.

> 
> What back ends are developed? Apart from a basic image buffer back end (I assume), what other back ends are being considered primary? SVG, PostScript, PDF, GDI+ and OpenGL all seem to be candidates.

The default implementation will be designed to render directly to byte arrays. I don't want to give too much info about implementation details just yet, as the design is still subject to change, but I can tell you right now there will be no direct support in the default implementation for rendering to anything other than byte arrays, nor for any renderer other than one implemented in software.

However, the design is such that users will be able to implement third party renderers and manipulate the bytes, or frame buffer, in anyway they need want. The default implementation is intended to be available anywhere Tango is, regardless of what third-party implementations are out there.

> 
> What external libraries will this depend on? I assume libpng and FreeType at the very least.

The default implementation will most likely have a dependency on FreeType. I don't see anyway around that right now. But there will be no dependencies on any sort of image library. What you do with the byte array after a rendering operation is totally up to you.

> 
> In all, it sound very interesting. I have personally several applications that could use this. There must have been a tremendous amount of work involved getting this done.
> 

It's very much a work-in-progress. I can't give you a date yet for when you'll see anything, but we wanted to announce it now to get some general feedback.

Mike Parker wrote:
> Dear D community
> 
> Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.
> 
> The API is designed to support third-party implementations for cases when the default (software) implementation does not fit the bill. These additional implementations are free to accelerate both the buffering and the rendering, and an OpenGL wrapper will likely be provided for those systems with OpenGL support. All implementations will support headless systems.
> 
> Contact:
> http://www.dsource.org/projects/tango/wiki/Contact
> 
> Signed,
> 
> The Tango Team
> 
> http://www.dsource.org/projects/tango/wiki/Contributors
> 
> ----
> 
> Tango is a cohesive runtime and library for the D programming language. A feature list can be found on http://www.dsource.org/projects/tango/wiki/Features

Sounds excelent! Will routines for loading various kinds of image formats (jpg, gif, etc.) be present here? I know Derelict has a wrapper for SDL_image, but perhaps a more D'ified version would be useful for a graphics library, *as well as just having a standard* Image type would be useful.
I say this since in this semester I've been working in C++ again, (in another university game project), and since I use several third-party code modules, I have about 3 different image loading libraries (and none of them is SDL_image nor is full featured like it :( ).

But I would also like to point out Oskar's point about monolithicness vs. modularity. As Tango gets bigger it does seem overkill to bundle all that functionality together, specially if it happens to start getting (non-core library) features useful outside of the server world.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Mike Parker wrote:
>> Dear D community
>>
>> Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.
>>
>> The API is designed to support third-party implementations for cases when the default (software) implementation does not fit the bill. These additional implementations are free to accelerate both the buffering and the rendering, and an OpenGL wrapper will likely be provided for those systems with OpenGL support. All implementations will support headless systems.
>>
>> Contact:
>> http://www.dsource.org/projects/tango/wiki/Contact
>>
>> Signed,
>>
>> The Tango Team
>>
>> http://www.dsource.org/projects/tango/wiki/Contributors
>>
>> ----
>>
>> Tango is a cohesive runtime and library for the D programming language. A feature list can be found on http://www.dsource.org/projects/tango/wiki/Features
> 
> Sounds excelent! Will routines for loading various kinds of image formats (jpg, gif, etc.) be present here? I know Derelict has a wrapper for SDL_image, but perhaps a more D'ified version would be useful for a graphics library, *as well as just having a standard* Image type would be useful.
> I say this since in this semester I've been working in C++ again, (in another university game project), and since I use several third-party code modules, I have about 3 different image loading libraries (and none of them is SDL_image nor is full featured like it :( ).

No, there will be nothing to handle any image formats. You can read more about it in my reply to Oskar.

> 
> But I would also like to point out Oskar's point about monolithicness vs. modularity. As Tango gets bigger it does seem overkill to bundle all that functionality together, specially if it happens to start getting (non-core library) features useful outside of the server world.
> 

Bruno Medeiros wrote:
> 
> But I would also like to point out Oskar's point about monolithicness vs. modularity. As Tango gets bigger it does seem overkill to bundle all that functionality together, specially if it happens to start getting (non-core library) features useful outside of the server world.

The modular design is still very much in place.  This is largely an issue of packaging.  As time goes on, there may well be a "core" Tango distribution with pluggable add-ons, as well as an inclusive distribution for those who prefer the monolithic style.  As a result, it's /possible/ that some of the recently announced packages may change locations to facilitate such packaging, if a more appropriate place can be found for them (all prior to 1.0, obviously).  Our goal for now is simply to make them available and to solicit feedback.


Sean

Mike Parker wrote:
> Oskar Linde wrote:
>> Mike Parker wrote:
>>
>>> Tango is going visual! Headless visual! With the addition of a general purpose 2D graphics package, Tango users will be able to generate 2D images on the fly for use in a variety of applications, on the server or the desktop. The package supports basic 2D primitives, complex shapes, fonts, alpha-blending, transformations, paths, styles, and other common 2D graphics operations. The design is inspired by several existing APIs, such as Java2D and OpenVG, so anyone who has experience with other APIs should be able to get up and running quickly.

Are you using a nice anti-aliased renderer to do the pixel pushing? Something like AGG ported to D would be cool.  It seems to be aiming at about the right level -- cross platform, only knows how to render to bitmaps internally.  I know there are folks using AGG for server side image gen (if not directly then at least thorough Matplotlib, which uses AGG as its renderer).

--bb

Bill Baxter wrote:
> Mike Parker wrote:

> 
> Are you using a nice anti-aliased renderer to do the pixel pushing? Something like AGG ported to D would be cool.  It seems to be aiming at about the right level -- cross platform, only knows how to render to bitmaps internally.  I know there are folks using AGG for server side image gen (if not directly then at least thorough Matplotlib, which uses AGG as its renderer).
> 
> --bb

I thought about porting AGG, but two things stopped me. For one, the design is rather horrid, IMO. It's a PITA to use and seems it would be an even bigger PITA to port. The real killer, though, is that the current version (2.5, IIRC) is GPL. The previous version has a less-restrictive license, but there's so much similarity between the two versions it just doesn't seem like a good idea.

For what we have right now, we're using a custom rasterizer and haven't yet implemented AA. I'm open to porting an existing rasterizer if there's a good one out there with a reasonable license.

Mike Parker wrote:
> Bill Baxter wrote:
>> Mike Parker wrote:
> 
>>
>> Are you using a nice anti-aliased renderer to do the pixel pushing? Something like AGG ported to D would be cool.  It seems to be aiming at about the right level -- cross platform, only knows how to render to bitmaps internally.  I know there are folks using AGG for server side image gen (if not directly then at least thorough Matplotlib, which uses AGG as its renderer).
>>
>> --bb
> 
> I thought about porting AGG, but two things stopped me. For one, the design is rather horrid, IMO. It's a PITA to use and seems it would be an even bigger PITA to port. 

Well, yeh, but once you get your head around it, and wrap it with a decent API, then it works quite nicely.  But that's in C++.  It would certainly not be trivial to port it to D.  The only thing you would really want to port would be the core operators and stream processors. Like the code used to generate offsets to paths (agg_conv_stroke) and the code that generates spans from geometry and fills them.

The real killer, though, is that the
> current version (2.5, IIRC) is GPL. The previous version has a less-restrictive license, but there's so much similarity between the two versions it just doesn't seem like a good idea.

So stick with AGG 2.4, which is a BSD-ish, I think.  I believe that's what a lot of AGG users are doing.  There was a little discussion about setting up a FreeAGG project somewhere just to maintain bug fixes, but at the time it was proposed, people were still hoping Maxim would change his mind about going GPL.


> For what we have right now, we're using a custom rasterizer and haven't yet implemented AA. I'm open to porting an existing rasterizer if there's a good one out there with a reasonable license.

AGG 2.4 is the best thing I know of -- small, light, fast, with good quality raster output.  But only raster output.  Cairo is obviously another candidate.  It aims to be cross platform and does support lots of back-ends (raster, ps, pdf, etc).   I guess it depends on how grandiose your goals are and how much time you realistically have to spend on the project.

--bb