Because SVG is slow (complex) itself.
The "Q"
Re: SVG is slooooow!
Because SVG is slow (complex) itself.
Novice
Re: SVG is slooooow!
Is that the case? I have never used SVG before. I am starting to write a Map Viewer app for work and I thought I'd look at SVG because it's new in Qt4.1. I take it SVG is not the way to go then....Originally Posted by wysota
The "Q"
Re: SVG is slooooow!
SVG is a vector format (scalable vector graphics) so rendering it to a bitmap is time consuming. I guess it won't be of much use for you to convert one vector format (the map) to another (svg) and then render it as a bitmap somewhere.
Novice
Re: SVG is slooooow!
I don't want to convert it to a bitmap - is that what the SVGViewer is doing? I want to display Vector graphics on a QWidget - isn't that what the QSvgRenderer does?
Sorry if this sounds stupid - I am no graphics expert!
The "Q"
Re: SVG is slooooow!
Displaying it on a widget means converting to a bitmap. After all, a widget is represented by a "picture" of the window and that "picture" consists of pixels.
Novice
Re: SVG is slooooow!
Hmmmm. I assumed Qt would be using QPainterPath or something to "draw" svg data using vectors. In fact, I'm sure that's what it's doing. If it was a raster bitmap then when I zoom in using the SVGViewer example, it would become pixelised but it doesn't.
The "Q"
Re: SVG is slooooow!
"Drawing" means "rasterising".
Yes, it is.In fact, I'm sure that's what it's doing.
Because the raster is recomputed and redrawn. That's the whole idea of vector graphics. But these are just vectors -- mathematical beings. To visualise them, they must be rasterised -- always. Just like a fractal -- it is a math formula, but to see it, you have to compute each pixel of it (so... rasterise it).If it was a raster bitmap then when I zoom in using the SVGViewer example, it would become pixelised but it doesn't.
Novice
Re: SVG is slooooow!
Yep, of course you are right, I told you I was no graphics expert!
Thankyou for your help in clearing this up in my head but I still have the same problem - the SVGViewer is unacceptably slow. If it's because SVG is complicated then fine, I will use something else. But I find it hard to beleive that drawing and zooming a simple map is too complicated these days when using hardware accelaration!
Novice
Re: SVG is slooooow!
The example seems to perform fine on my computer. But I do have a pretty fast machine, AMD Athalon XP 3200 w/ 1GB of ram.
I just have a question regarding that example. What's the difference between the three renderers? Even from the source code, I am not sure I understand. The SvgRasterView (used for Image), renders on top of an image; SvgNativeView (for Native) renders on top of the widget (this), and SvgGLView paints on top of the QGLWidget (this). I dont really know what this means? Clearly there is a difference between the 3 modes. The native one usually has transparent background when viewed. Same for OpenGL renderer. Also, for me OpenGL renderer doesn't look as good. Image one doesn't have transparent background. Quality wise, Native and Image look the same, and better than OpenGL.
Also why are they setting viewport in the Native one but not in the OpenGL one? Sorry if these are newbie questions; or if this is OT for this thread.
Bojan
The march of progress:
C:
printf("%10.2f", x);
C++:
cout << setw(10) << setprecision(2) << showpoint << x;
Java:
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance();
formatter.setMinimumFractionDigits(2);
formatter.setMaximumFractionDigits(2);
String s = formatter.format(x);
for (int i = s.length(); i < 10; i++) System.out.print(' ');
System.out.print(s);
Novice
Re: SVG is slooooow!
Yes, yes, yes! Finally, someone agrees with me! I have posted messages to qt-interest about this with no reply. What is going on?
Again, I totally agree. On my machine, the OpenGL is even worse - if you zoom in to far the image becomes totally scrambled and messed up. Could you try that on your machine please and see if the same happens?
As I've had no response from qt-interest I have just read and read the documentation and studied the example. It seems, the Arthur paint engine does indeed support multiple paint engines (such as PostScript and opengl) but this isn't an abstraction - you must derive from QGLWdiget to use OpenGL, and you must derive from QPSPrinter to use PostScript.
Although it's not as impressive as I initially thought, I can live with it as long as the OpenGL examples works. But in SVGViewer, as you state the OpenGL provides no visible performance improvement - in fact, it looks and performs worse than the other renderers.
What is going on?
Intermediate user
Re: SVG is slooooow!
I get stop-go playback in "Native" & "Image" mode, but get smooth playback with "OpenGL". My machine is also just decent (P4 2.4 (800) 512 MD DDR400 FX5200 128 MB)
EDIT: Also default opened graphic "bubbles.svg" is a bit complex, try "spheres.svg"
Last edited by yogeshm02; 13th February 2006 at 05:19.
Posting Permissions
Reply With Quote
Bookmarks