Moving from Qwt 5.2 to 6.0 (trunk)

I was trying to move my code from Qwt 5.2 to the trunk which is to be the new 6.0, and the axis labels are either left or right justified instead of centered.

Is this by design or did I do something wrong?

Thanks,
Joey

Quote:

---

Originally Posted by bigjoeystud

Is this by design or did I do something wrong?

---

And what is it what you did ?

Uwe

?????

I ported the code from 5.2 to the trunk, just like I said. However, the QwtTexts are being justified to the edges of the axes. If I surround the text with center tags, I get the old output. Maybe there is a float that should be an int or vice versa either in my code or elsewhere or is that a new default?

Also, in qwt_symbol.h, the setSize takes two ints, but the default argument is a float.

Are you talking about labels in the Qwt examples ? If yes I can tell you it is not intended and it doesn't happen on my box.
If not it's not enough to write that you have ported some code - you have to tell us about the code you have now.

Uwe

Try this:

In plot.cpp in the bode example, line 60:

- setAxisTitle(QwtPlot::yRight, "Phase [deg]");
+ setAxisTitle(QwtPlot::yRight, "<i>Phase [deg]</i>");

Once making this change, the right axis is now justified along the top of the axis on my box since it now uses the RichText API.

Is that by design or not, or does this only happen on my Linux box?

Thanks,
Joey

Ok, now I can see it: the rich text label is aligned left, while the plain text label is centered.

The alignment of the plain text label is like expected, but the position of the rich text is not intended. Looks like I had removed the code, that sets the alignment alignment flags internally by accident.

Fixed in SVN,
Uwe

One more problem noticed in printing, but I'm at a loss for how to duplicate this problem in the example codes.

I'm printing a grid of QwtPlots and there can be more of them than there is room so I scale the coordinate system with painter.setWindow (rect). At least, that is what I used in the past (5.2). With the new version, I use either painter.setWindow (rect.toRect ()) or painter.setWindow (rect.toAlignedRect ()), and I get all the boxes (axes/scaling/etc) and the line plots looking correct; however, any spectrograms (i.e. rasters) are not printed correctly. It is like it is not scaling the rasters since I see what looks like the top of the raster unscaled.

Does that make sense? Any ideas on what I could look at to try and fix this?

Thanks,
Joey

Qwt 6-x uses a double based render engine, what makes it possible to print with a scaled painter without losing precision for all vector graphics. Raster data is different as any scaled image is worse compared to an image that is rendered in device coordinates.

That's why QwtPlotRasterItem fiddles around with the painter transformation, using it for finding the bounding rect of the image but disabling it for rendering the image and painting it later. Guess there is a bug in combination with QPainter::setWindow.

The code can be found in QwtPlotRasterItem::draw. The important code is the calculation of paintRect and all lines with the painter.

Uwe

I had a look at the code myself: instead of resetTransform a identity transformation has to be set if I don't want to kill a setWindow transformation.

Fixed in SVN trunk,
Uwe

Darn! Found another problem... (but all of the fixes in SVN thus far are great!)

I am plotting some rasters which have a Y range of 0 to 180 with nine values of Y and I would normally see the image filled throughout the box. With the new version, I see only eight values of the Y and the top row is blank!

In debugging, I see that in QwtPlotRasterItem::draw, the yMap and canvasRect are correct, but when it gets to computing imageArea, the rectangle now starts at 0.847, rather than 0. When it gets into QwtPlotSpectrogram::renderImage, the scale interval is 0.847 to 180.847. Thus, when it is in my code (subclass of QwtRasterData::value) looking for the data, the Y value being sent in is 180.847 which is outside the range so that is why it is drawing the blank region.

I don't see this on all my plots, just the cases where I am going from 0 to something. At least I think that is the common denominator.

Any ideas?

Thanks,
Joey

A final note - commenting out the paintRect.translate(tr.m31(), tr.m32()); line in QwtPlotRasterItem::draw fixes this problem. However, taking this line out makes the inner/outer ticks not line up correctly when printing. Not good either... Other ideas welcome.

Joey

Applying the translations in QwtPlotRasterItem::draw() was implemented wrong, but the reason for your problem are rounding errors when translating QRectF->QRect->QRectF using the scale maps. This is a general problem that can't be avoided when rendering a QImage to a double based system ( similar to the resampling you need to do in YourRasterData::value() ).

But at least what can be done is to avoid, that the rounding errors lead to requests outside of the bounding rect.

Done in SVN,
Uwe

Things are looking really good, but I found one more problem.

I plot multiple spectrograms in a single QwtPlot, and with the latest version from trunk (767), my upper spectrogram is below the lower spectrogram (i.e. the plot is reversed along the Y axis, but correct in X)! With revision 766, this problem does not occur.

The problem seems to be that yMap.p1 is greater than yMap.p2 creating a negative height. The following change seems to fix it, but probably not the best solution.

Joey

--- qwt_plot_rasteritem.cpp (revision 767)
+++ qwt_plot_rasteritem.cpp (working copy)
@@ -248,7 +248,8 @@
xxMap.setPaintInterval(mapRect.left(), mapRect.right());

QwtScaleMap yyMap = yMap;
- yyMap.setPaintInterval(mapRect.top(), mapRect.bottom());
+ if (yMap.p1 () > yMap.p2 ()) yyMap.setPaintInterval(mapRect.bottom(), mapRect.top());
+ else yyMap.setPaintInterval(mapRect.top(), mapRect.bottom());

Quote:

---

The problem seems to be that yMap.p1 is greater than yMap.p2 creating a negative height.

---

No, that is normal and doesn't invert the transformed map.

I tried a couple of combinations with the spectrogram example, but never ran into situation where the directions of y axis and spectrogram are inverted.

Please try to change the spectrogram example, demonstrating your problem.

Uwe

I think it has to do with autoscaling of the axes, since if I plot the two spectrograms separately; things look pretty good. Anyway, here a modification of the spectrogram example. The only thing I am changing is the starting position of Y and adding the other spectrogram to the same box.

================================================== =================
--- plot.cpp (revision 767)
+++ plot.cpp (working copy)
@@ -54,6 +54,29 @@
}
};

+class UpperSpectrogramData: public QwtRasterData
+{
+public:
+ UpperSpectrogramData():
+ QwtRasterData(QRectF(-1.5, 2.5, 3.0, 3.0)) // change starting position of Y
+ {
+ }
+ virtual QwtDoubleInterval range() const
+ {
+ return QwtDoubleInterval(0.0, 10.0);
+ }
+
+ virtual double value(double x, double y) const
+ {
+ const double c = 0.842;
+
+ const double v1 = x * x + (y-c) * (y+c);
+ const double v2 = x * (y+c) + x * (y+c);
+
+ return 1.0 / (v1 * v1 + v2 * v2);
+ }
+};
+
Plot::Plot(QWidget *parent):
QwtPlot(parent)
{
@@ -87,6 +110,12 @@
d_spectrogram->data()->range().maxValue() );
enableAxis(QwtPlot::yRight);

+ QwtPlotSpectrogram *d_spectrogram2 = new QwtPlotSpectrogram();
+ d_spectrogram2->setRenderThreadCount(0); // use system specific thread count
+ d_spectrogram2->setColorMap(colorMap);
+ d_spectrogram2->setData(new UpperSpectrogramData());
+ d_spectrogram2->attach(this);
+
plotLayout()->setAlignCanvasToScales(true);
replot();

Well, this wasn't one of my best codes ever. I also found another alignment problems + a nonworking cache mode. So I decided to rewrite QwtPlotRasterItem::draw.

Done in SVN,
Uwe

Awesome! Thanks Uwe! I think most everything is working with regard to my porting from Qwt 5.2 to 6.0 and I've been testing quite a bit. I have one other problem which has been in Qwt for as long as I can remember, and it has to do with the QwtScaleEngine::Floating. I noticed you made some changes to qwt_scale_engine, and this use to hang before, but now it just doesn't look good. Maybe it's a simple fix? Anyway, here's a diff to the sinusplot example showing the problem:

Code:

---

Index: sinusplot/sinusplot.cpp
===================================================================
--- sinusplot/sinusplot.cpp     (revision 773)
+++ sinusplot/sinusplot.cpp     (working copy)
@@ -2,6 +2,7 @@
 #include <qwt_plot.h>
 #include <qwt_plot_marker.h>
 #include <qwt_plot_curve.h>
+#include <qwt_scale_engine.h>
 #include <qwt_legend.h>
 #include <qwt_series_data.h>
 #include <qwt_text.h>
@@ -51,8 +52,23 @@
     setAxisScale(xBottom, 0.0, 10.0);
 
     setAxisTitle(yLeft, "y -->");
-    setAxisScale(yLeft, -1.0, 1.0);
+//    setAxisScale(yLeft, -1.0, 1.0);
+
+    QwtScaleEngine *se = new QwtLog10ScaleEngine ();
+    se->setAttribute (QwtScaleEngine::Floating, true);
+    setAxisScaleEngine (yLeft, se);
+
+    unsigned int nPoints = 10;
+    QVector <QPointF> samples (nPoints);
+    for (unsigned int i = 0; i < nPoints; ++i) {
+        samples [i] = QPointF (i, rand () % 3307 + 41878);
+    }
+    QwtPlotCurve *crv = new QwtPlotCurve ("Bad");
+    crv->setSamples (samples);
+    crv->setStyle (QwtPlotCurve::Lines);
+    crv->attach (this);
 
+/*
     // Insert new curves
     QwtPlotCurve *cSin = new QwtPlotCurve("y = sin(x)");
     cSin->setRenderHint(QwtPlotItem::RenderAntialiased);
@@ -89,6 +105,7 @@
     mX->setLinePen(QPen(Qt::black, 0, Qt::DashDotLine));
     mX->setXValue(2.0 * M_PI);
     mX->attach(this);
+*/
 }

---

QwtLog10ScaleEngine::divideScale falls back on a linear scale engine, when the interval is less than a "decade", while QwtLog10ScaleEngine::autoScale doesn't. You are running into this bug with the Floating flag only, because otherwise the intervals gets aligned to a "decade".

I have added the same fallback strategy to QwtLog10ScaleEngine::autoScale.

Uwe

Thanks Uwe!

One other problem I am having is the inner ticks (QwtPlotScaleItem) no longer align with the outer ticks!

If I remove the Floating flag, all the ticks are lined up.

However, I can't seem to duplicate this behavior with the sample program, and I'm not really sure why. I feel like it is some order of operations issue. I am subclassing the QwtScaleDraw, but I am only overloading the label.

Anyway, do you have any ideas?

Joey