www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Tango Graphics Package

reply Mike Parker <aldacron71 yahoo.com> writes:
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
Jul 11 2007
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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
Jul 11 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Jul 12 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Jul 12 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Jul 12 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Jul 12 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Jul 12 2007
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
 
Jul 12 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Jul 12 2007