Qwt canvas using QGLWidget?

Is it possible to use Qwt on top of QGLWidget?

Quoting http://doc.trolltech.com/4.7/opengl-2dpainting.html :
The 2D Painting example shows how QPainter and QGLWidget can be used together to display accelerated 2D graphics on supported hardware.

Since QwtPlotCanvas serves as a QPainter for all the plot items, maybe it would be possible to use QGLWidget in there somewhere? I'm asking because our custom plot items are rendering quite slowly, and maybe (I'm not sure, but just maybe) GL-based rendering would be faster?

Thanks

Quote:

---

Originally Posted by alex_sh

Is it possible to use Qwt on top of QGLWidget?

---

No.

Some time ago I played with an OpenGL plot canvas and for a couple of situations things were faster, for others it was slower. The main reason for this surprising result was that in combination with OpenGL the canvas got only update requests for its complete size ( also incremental painting is not possible at all. ) But this is a couple of years ago - maybe things have improved since then.

I decided to implement an optional OpenGL canvas not before Qt3 support has been dropped. So it is on my TODO list now - but not for Qwt 6.0 anymore.

Quote:

---

Since QwtPlotCanvas serves as a QPainter for all the plot items, maybe it would be possible to use QGLWidget in there somewhere?

---

The plot canvas itsself is no problem at all - it's more about organizing its backing store ( paint cache ), that can't be a QPixmap then.

Quote:

---

I'm asking because our custom plot items are rendering quite slowly, and maybe (I'm not sure, but just maybe) GL-based rendering would be faster?

---

I don't know about your plot items, but in general it's more effective to avoid painting instead of trying to accelerate it. Often weeding and clipping or other optimizations for your specific situation are more important.

When you are talking about raster items with a certain resolution almost all time should be lost in the image composition ( that needs to be done by the CPU ). Here using OpenGL would have no notable effect at all - better try to improve the image composition.

Uwe

Thanks for your clear explanation!
I'm already doing clipping with my items, but the fully zoomed out plotting takes quite some time. I'll try to come up with some kind of weeding algo for these items.

So I guess you have curves ( or something similar ) with many points.

The usual type of solution for this problem is to work with different sets of points for different levels of detail. When you zoom in you would activate a more detailed data set - but the clipping will be successful to sort out most points before they will be painted. In zoomed out mode many points would be mapped to the same position on the canvas - so you could use a data set with less points.

Switching between the different data sets can be done according to QwtScaleWidget::scaleDivChanged() signals. For weeding you can use Douglas/Peucker - it is implemented as QwtWeedingCurveFitter. Note, that weeding is to slow to be done each time a curve is painted ( QwtPlotCurve::setCurveFitter() ), but you can also use it to calculate a couple of data sets for your levels of detail once in the beginning.

I recommend to implement your own type of QwtSeriesData class, that returns the samples from the "active" data set.

Uwe

PS: A data class, that implements these level of details is also on my TODO list for 6.1

Thanks.
We do have some curves with many points and I'll be looking forward to use the class you described in 6.1.
That, however, is not where our performance problem lies. Our custom item (a triangle mesh with lots of triangles) is the culprit. I think the main performance hit comes from a situation where lots of very small (color-filled) triangles are clustered together. If the same number of triangles is scattered evenly, there's no slowdown. I'll do some profiling and try and see if we can omit the rendering or filling some of them (or just replace them with dots) if all 3 points map to the same pixel.
Thanks again for the suggestions!