SVG is slooooow!

[Paul Drummond]

Hi,

Has anyone else noticed the bad performance of the svgviewer example which comes with Qt4.1? If you zoom in a bit then scroll around, it's not very smooth.

Also, when swiching to the OpenGL renderer, there is no obvious improvement!

I don't understand why it's so slow (it's not my machine - I have tried this on three different machines now, 2 in Windows, 1 in Linux). The "affine" demonstration (the one which scales and rotates a vector penguin) is a smooth as it gets so why is the SVGViewer so bad???????

[wysota]

Because SVG is slow (complex) itself.

[Paul Drummond]

Because SVG is slow (complex) itself.

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....

[wysota]

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.

[Paul Drummond]

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!

[wysota]

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.

[Paul Drummond]

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.

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.

[wysota]

Hmmmm. I assumed Qt would be using QPainterPath or something to "draw" svg data using vectors.

"Drawing" means "rasterising".

In fact, I'm sure that's what it's doing.

Yes, it is.

If it was a raster bitmap then when I zoom in using the SVGViewer example, it would become pixelised but it doesn't.

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).

[Paul Drummond]

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!

[Bojan]

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

[Paul Drummond]

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?

Yes, yes, yes! Finally, someone agrees with me! I have posted messages to qt-interest about this with no reply. What is going on?

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.

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?

[yogeshm02]

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"