Scatter plot with custom symbols

[jcox23]

Hi there,

I'm trying to put together a scatter plot widget where each symbol can be customized to convey a 3rd dimension of data...
by changing the size and/or the color of the symbol for example
(something in that fashion if not clear:http://matplotlib.sourceforge.net/pl...sked.hires.png)

I modified a bit the realtime plot example, setting up a new symbol each time a data point is appended but
when the widget is resized or zoomed in, everything is redrawn using the current last symbol....

It's probably not that complicated but I think I need an eye opener from someone...
as for now, the solution I see is creating a new drawSymbols function that would take an array of QwtSymbol as input...

Thanks for any help

[Uwe]

In the devlopment branch of Qwt ( SVN trunk ) you can find an item ( QwtPlotCurve3D ), that maps the z value into colors. There is also code available for mapping the z value into the symbol size, but has not been committed yet. But be warned the final design of this class is not decided, so better copy it into your project.

[jcox23]

I just checked that out thanks!

Just for my education, did you actually considered using an array of symbols?
I see that you create a new symbol before drawing and delete it straight away....
Is there any performance concern in doing that?

On an unrelated topic, I saw a comment of yours about OpenGL, saying that it would be a bad performer as
the widget has to redraw itself entirely all the time...
It's true, but if you use modern OpenGL and store the data on the GPU (because you used VBOs), a redraw operation
should not be that costly... but even if it is, OpenGL has FrameBuffer Objets... which would be used in the same fashion you cache into a Pixmap currently....

[Uwe]

Just for my education, did you actually considered using an array of symbols?

The basic idea of this class is to map the z value to a colored dot via a color map. But there are so many other ways how the z value could be displayed ( symbol type/size, direction of an arrow symbol ... ), that its hard to design a class, that is able to handle them all.

Maybe I will introduce a base class for a 3D points curve with a pure virtual method:
"virtual void drawPoint(const QPointF &pos, double z) = 0", but in the end deriving from QwtPlotSeriesItem<QwtDoublePoint3D> is also an easy way to implement optimized painting code.

I see that you create a new symbol before drawing and delete it straight away....
Is there any performance concern in doing that?

Sure it is and don't use it for trillions of points - but this doesn't make much sense for this type of representation at all.

On an unrelated topic, I saw a comment of yours about OpenGL, saying that it would be a bad performer as the widget has to redraw itself entirely all the time...
It's true, but if you use modern OpenGL and store the data on the GPU (because you used VBOs), a redraw operation should not be that costly... but even if it is, OpenGL has FrameBuffer Objets... which would be used in the same fashion you cache into a Pixmap currently....

My note was about incremental painting, something you can see in the realtime/oscilloscope examples. The interesting fact is, that for certain situations/environments you would have worse performance using the hardware accelerated path of OpenGL (that is not supported by Qwt yet).

Uwe

[jcox23]

Before using the trunk version (btw the friedberg example is gorgeous), I modified the 5.2.0 version...messing around the DrawSymbols method
to get a better understanding of what's going on in there...

I managed to get something close to what I wanted...see attached

The basic idea of this class is to map the z value to a colored dot via a color map. But there are so many other ways how the z value could be displayed ( symbol type/size, direction of an arrow symbol ... ), that its hard to design a class, that is able to handle them all.

That's why I thought first of an array of symbols...
DrawSymbols would expect an array of symbols, the user being in total control
of what to put in there... implementing the 3d in whatever aspect...

The way you implemented QwtPlotCurve3D is of course more user-friendly...

Maybe I will introduce a base class for a 3D points curve with a pure virtual method:
"virtual void drawPoint(const QPointF &pos, double z) = 0", but in the end deriving from QwtPlotSeriesItem<QwtDoublePoint3D> is also an easy way to implement optimized painting code.

Sure it is and don't use it for trillions of points - but this doesn't make much sense for this type of representation at all.

My note was about incremental painting, something you can see in the realtime/oscilloscope examples. The interesting fact is, that for certain situations/environments you would have worse performance using the hardware accelerated path of OpenGL (that is not supported by Qwt yet).

Uwe

I thought OpenGL would be a way to get rid of these platform-dependant stuff concerning incremental painting, and still having very good performance...
rendering to a FrameBuffer, so you only render the framebuffer, instead rendering all the points each time a point is added... I cant state that as a fact though...
and recent blog posts of the Qt team showed as you said that sometimes OpenGL is not very faster than X11...