The problem is that there is no Open Source implementation. And the implementation that claims to be the reference implementation is closed. It'ss a rather silly situation, especially given how important vector graphics is becoming on our desktops/mobile devices nowadays.
After this introduction I'm sure you already know that I went ahead and started an Open Source implementation of OpenVG. I did it on top of QtOpenGL. The main reason for it is that QtOpenGL, quality and speed wise (in Qt 4.3) beats everything out there - every vector graphics framework.
So, there's a git repository at:
http://gitweb.freedesktop.org/?p=users/zack/openvg.git;a=summary
there's an example included, that animates and looks like this:
Gears demos are mandatory for any kinds of hardware accelerated API it seems ;) Oh, and due of all the extra features that went in Qt 4.3, Qt snapshots are currently required to compile it. I'm not sure where this is going to go. It will largely depend on whether there's real interest in it. In general I think it'd be interesting to see KDE have a library that would allow running of OpenVG based content right on KDE. It could be potentially an incredibly powerful feature of KDE as a platform, to support the hardware accelerated vector graphics api.
16 comments:
it's a great idee !!!!!!
you rocks
Thank you! I really wanted opensource OpenVG implementation.
Btw. how complete is your implementation now? Is something missing?
The main reason for it is that QtOpenGL, quality and speed wise (in Qt 4.3) beats everything out there - every vector graphics framework.
Hmm are you sure? Based on my experience (I haven't benchmarked them) I'd be surprised if it beats agg (www.antigrain.com).
Why don't you announce this implementation on the xorg mailinglist?
Some answers:
- it's pretty complete but a few important things are missing. Most notably support for patterns. It's pretty trivial to add it though because Qt's rendering engine has feature parity with OpenVG.
- Yes, I'm sure. AGG is excellent but all software, even a pretty naive hardware based implementation will beat it by the virtue of having a lot of extra processing power at its disposal. And Qt's OpenGL pipeline is /very/ fast and well done.
- No reason, just haven't gotten around to send the email.
Are you familiar with Amanith and AmanithVG? http://www.amanith.org/include/about.php
http://www.amanithvg.com/project.html
Apparently Amanith is open-source and also based on OpenGL, though I'm not clear on AmanithVG...
Well, I surely would use it, if it would not depend on Qt at all. (Sorry, that's just me).
Is your implementation in C++ (propably is, just like Qt)?. Then that's strange as OpenVG is a C API (who says I know anything...). Would that make your implementation of OpenVG incomplete as it propably wouldn't be usable from C. ???
Just thinking out loud, without knowing anything really, so don't be offended.
What I'd really like to see, is an OpenVG implementation with at least LGPL license, and written in C. That would propably benefit the whole opensource community, and not just Qt/KDE.
And, no, I'm not writing my apps in C, but in a language called
char c = 'c'+1;
writefln(c);
Yo Jeff,
Amanith is a sort of open source vector graphic framework, with a drawing backend based on OpenGL, and it's written in C++.
AmanithVG is a lightweight commercial OpenVG implementation, written in pure ANSI C. It support different drawing backends: OpenGL (both fixed and shader pipelines), OpenGLES (1.1 and 2.0).
Of course it's crossplatform, we have working version on desktops with Windows, Linux, MacOSX, Freebsd, Irix and on some embedded platforms (OpenGLES 1.1 enabled) running WinCE, LinuxEmbedded and Symbian S60.
Returning to the Zack OpenVG implementation, i'm really happy to see this big interest in the khronos APIs. I wish to see, as soon as possible, a lot of coders that uses OpenVG to develop their amazing applications !
Ska - Amanith Team
Well done dude! Thanks a lot
Now we want a Flash-like application that works with VG and implements OpenVG so it can be damn fast.
Also like someone said before, please try to make it usable for non-kde guys. Or maybe collaborate with Gnome or Xfce or enlightement teams or whoever to figure what can be done because I don't know anything about VG ; Using Inkscape a lot doesn't mean you know something about VG, does it.
So _Please_ continue to good work.
Well, the only reason I listed something that I want, was that zack asked for it in the khronos forums:
Direct quote:
"All in all, the dependency on Qt and the license could change. I'm more interested in whether people are interested in having an Open Source OpenVG implementation and if so what they would like to see. "
So, atleast I took that as an encouragement to post what I'd like to see/what I need/what I want. And my "demands" are not directed to zack, but to the whole open source community.
And, yes, it's great to see the first opensource OpenVG implementation see daylight. Thank you Zack!
Jeff: Amanith (even if it use OpenGL) is _much_ slower than Qt 4 Arthur engine. Look at this Zack Rusin's benchmark. Same for Agg.
Btw. I am happy that this OpenVG implementation is based on Qt. Please don't change it ;-)
Amanith results slower that Qt/Arthur in Zack benchmarks because they aren't meaningful ;) As i made people notice, it's a sort of ridiculous test, forcing the API to not cache results. In 95% of usage cases, caching is a natural benefit (think about static paths, or paths animated through matrices, GIS viewers, SVG / Flash players, desktop icons / themes, and so on).
In these 95% cases the method of Zack results *much* more slower than a common caching system, because it requires 2 drawing passes per primitive. He can confirm this without problems. And that's the reason he's refusing to do common cases tests :)
In addition on mobile platforms stencil buffer is not present, just to say something, so Zack's method isn't available ;)
Please note that Amanith works very well also on gfx boards where shaders are not available, with all complex blend modes and paints type.
"What I'd really like to see, is an OpenVG implementation with at least LGPL license, and written in C. That would propably benefit the whole opensource community, and not just Qt/KDE.
And, no, I'm not writing my apps in C, but in a language called
char c = 'c'+1;
writefln(c);"
exactly the same reason im looking for open source OpenVG implementation with C API, too
Just a heads-up for some of the commenters, writing a library in C++ does not prevent it having a C-only API. See for example libfam or mesa's libGLU.
(Sorry if this is an old post, I don't see any dates on the comments)
Yes, we know... but if C API is not officially supported by the project, creating one yourself for every major update of the lib is too much work
Post a Comment