I'm looking at some older code which is rendering some images, animations, etc... for a website by generating a web page containing significant SVG elements. The result is a fairly complicated, interactive, interface. I've been tasked with migrating the application to instead generate WebGL calls.
This is a non-trivial task, considering all of the niceties that come with SVG, which are not directly available if going straight to a WebGL implementation. I've been debating whether I should pitch migrating to using something like Three.js instead, but don't know enough about the available options to make a good decision.
What are some reasonable options I should consider when trying to build my battle plan here?
I would suggest you look at http://code.google.com/p/canvg/ as an option.
I assume it is using getContext("2d") not getContext("experimental-webgl") or getContext("webgl").
WebGL provides a 3d interface and I am not sure if there is any advantage to using it for 2d graphics, since you don't have any 3d transforms for the GPU to work on. If they are interested in Canvas not specifically webgl ... Canvg would bring over some of the niceties of SVG which would be the source content.
If the issue is lack of support for SVG in browsers http://code.google.com/p/svgweb/ goes a long way to solving that problem.
Related
The graphics in Flash and non-fullscreen is anti-aliased and really smooth. But when go fullscreen or on mobile, the graphics become aliased. Even when I use SVG image.
Yes Flash has some great aliasing with software cpu based rendering. In the mobile targets of HaxeFlixel there is a method for drawing that is very different, mostly for performance reasons.
In HaxeFlixel the mobile and cpp targets will use the gpu which is more like webgl or Flash's Stage3d. This means that there will be differences in the way things like edges of images and text look.
Flixel and OpenFL do a very good job in making these two methods as similar as possible. Some recent work on text for cpp in OpenFL has been very impressive. I am not aware of any solution that makes the two pixel perfect in a complex game engine for every use case. You will find similar differences with aliasing in flash game engines like Starling which also use the gpu.
Some things you can try:
For OpenFL/HaxeFlixel I have set gpu antialiasing before, this should be the default:
<window antialiasing="4" />
If you are wanting to test, you will loose performance however I believe you can still set software rendering in cpp with.
FlxG.camera.antialiasing = true;
You mention SVG, I think you are assuming since its a vector format it should render perfectly. The gpu rendering first rasterises the image to a bitmap so if you are expecting it to scale etc like it does in the browser it wont. You could in this case use a higher resolution image and scale it down first.
What's the simplest, most reliable way to test if a browser / user agent / client supports the Raphael.js library? Raphael uses Javascript to create and control SVG vector graphics, or, if SVG isn't available but VML is (e.g. in Internet Explorer versions 6 to 8), it creates and controls equivalent graphics using VML.
One method would be to feature-detect SVG, then, if it's not available, feature-detect VML. There's an old question from 2009 with answers including some code for feature-detecting VML and SVG. However, the comments suggest that it might not work in all cases, and I'm sure a lot has changed since 2009. Also, there might be a simpler way specific to Raphael.
A simpler alternative might be to use some Raphael internal flags or functions. It already sets variables for whether it is operating in SVG mode or VML mode. Can this be used to reliably detect a 'neither' condition?
Or maybe there's a reliable approach based on creating an empty Raphael object and testing its properties or functions?
For general background, as far as I know the only common browser to not be compatible with Raphael is the Android stock browser in versions 1.x and 2.x, however, I'd prefer to use feature detection rather than browser version detection if possible (unless there's a good reason why that's actually unusually a better solution in this case).
Check the official docs: http://raphaeljs.com/reference.html#Raphael.type
if (!Raphael.type) alert('Your browser does not support vector graphics!');
I read while Googling that SVG was "dead". Although I disagree, could anyone tell me more/future vector based format to represent 2d/3d graphics? What about VML? What format should I use to represent 2D and 3D graphics on Web?
I playing around with graphics on web and I would like to know if I'm working with an obsolete technology.
Microsoft is supporting SVG in IE9, and gave a detailed explanation of why they were doing it on the IE blog:
http://blogs.msdn.com/b/ie/archive/2010/03/18/svg-in-ie9-roadmap.aspx
SVG's main advantage is that it becomes part of the DOM, so you can use CSS to style it and javascript to modify it. Canvas, by contrast, must redraw every frame completely. This makes canvas suited to spectrum analyzers, video processing, fast-paced games, and other non-gradual animations. SVG is better suited for gradual animations.
As far as 3D is concerned, the future is WebGL, a thin shim over OpenGL ES, but it's far off. Microsoft has not committed to supporting it, and that means it's not going to be in IE9. Maybe IE10, maybe not.
If you do use SVG, I recommend using svgweb to abstract away the browser differences (falls back to a flash applet on outdated browsers).
This post is rather late... but I think it is worth re-addressing, since your question has popped up again with all the html5 talk.
SVG is a vector drawing format that also supports animation, timing, and Javascript DOM support. In other words, it is a standalone format for static and dynamic vector graphics; you might say it is a web-focused (or screen-focused) alternative to EPS/PDF. The html5 canvas tag is not a format but a way to draw (static images) to the screen with Javascript — that is all; there is no competition between it and SVG, as they have entirely different purposes.
Most other vector "formats" involve plugins (Flash) or hardware support (webGL). Ironically, the VML format you mentioned is now deprecated in favor of SVG.
To answer your question: SVG is now the standard vector format for the web. Hopefully, in the near future, we will see it being used for video/animation as well.
You can try the Raphaël JavaScript Library.
It is easy to implement and provides the same UI features as SVG (and more!).
If it is SVG you are after the best way to go is svg.js. It supports SVG better and it is a fraction of the size (4.5k gzipped) of Raphaël (31k gzipped). It also has a very intuitive syntax.
All major browsers including ie9, firefox, safari and chrome are starting to supporting svg as part of the upcoming html5 standard. I wouldn't call that "dead"
2D: SVG
3D: X3DOM or webGL directly
We are considering using SVG filters as part of our toolchain, serving the SVG to browsers capable of supporting it, while serving pre-rendered PNGs to other.
One problem we noticed is that the rendering of the filter chains seems to be very inconsistent across renderers. When looking at the "filters01" example from the SVG specification, the rendering looks very different across the tools we tried. Chrome (5.0.307.11) failed to render the image, while other tools (Firefox 3.6, Opera 10.10, Inkscape 0.47, GIMP 2.6.7) render something vaguely similar in style to the picture in the specification, but no two are truly the same.
Is that an issue of under-specification or are the tools just not there? If we would use SVG with filter effects: is there a reference tool that can give us a rendering the way it is intended by the spec?
Please report bugs on at least anything that doesn't look the same from a meter away to help improve the situation.
I woud like to create a cross-platform drawing program. The one requirement for writing my app is that I have pixel level precision over the canvas. For instance, I want to write my own line drawing algorithm rather than rely on someone elses. I do not want any form of anti-aliasing (again, pixel level control is required.) I would like the users interactions on the screen to be quick and responsive (pending my ability to write fast algorithms.)
Ideally, I would like to write this in Python, or perhaps Java as a second choice. The ability to easily make the final app cross-platform is a must. I will submit to different API's on different OS'es if necessary as long as I can write an abstraction layer around them. Any ideas?
addendum: I need the ability to draw on-screen. Drawing out to a file I've got figured out.
I just this week put together some slides and demo code for doing 2d graphics using OpenGL from python using the library pyglet. Here's a representative post: Pyglet week 2, better vertex throughput (or 3D stuff using the same basic ideas)
It is very fast (relatively speaking, for python) I have managed to get around 1,000 independently positioned and oriented objects moving around the screen, each with about 50 vertices.
It is very portable, all the code I have written in this environment works on windows and Linux and mac (and even obscure environments like Pypy) without me ever having to think about it.
Some of these posts are very old, with broken links between them. You should be able to find all the relevant posts using the 'graphics' tag.
The Pyglet library for Python might suit your needs. It lets you use OpenGL, a cross-platform graphics API. You can disable anti-aliasing and capture regions of the screen to a buffer or a file. In addition, you can use its event handling, resource loading, and image manipulation systems. You can probably also tie it into PIL (Python Image Library), and definitely Cairo, a popular cross-platform vector graphics library.
I mention Pyglet instead of pure PyOpenGL because Pyglet handles a lot of ugly OpenGL stuff transparently with no effort on your part.
A friend and I are currently working on a drawing program using Pyglet. There are a few quirks - for example, OpenGL is always double buffered on OS X, so we have to draw everything twice, once for the current frame and again for the other frame, since they are flipped whenever the display refreshes. You can look at our current progress in this subversion repository. (Splatterboard.py in trunk is the file you'll want to run.) If you're not up on using svn, I would be happy to email you a .zip of the latest source. Feel free to steal code if you look into it.
If language choice is open, a Flash file created with Haxe might have a place. Haxe is free, and a full, dynamic programming language. Then there's the related Neko, a virtual machine (like Java's, Ruby's, Parrot...) to run on Mac, Windows and Linux. Being in some ways a new improved form of Flash, naturally it can draw stuff. http://haxe.org/
QT's Canvas an QPainter are very good for this job if you'd like to use C++. and it is cross platform.
There is a python binding for QT but I've never used it.
As for Java, using SWT, pixel level manipulation of a canvas is somewhat difficult and slow so I would not recommend it. On the other hand Swing's Canvas is pretty good and responsive. I've never used the AWT option but you probably don't want to go there.
I would recommend wxPython
It's beautifully cross platform and you can get per pixel control and if you change your mind about that you can use it with libraries such as pyglet or agg.
You can find some useful examples for just what you are trying to do in the docs and demos download.