qwt-interest — Qwt Q&A

Re: optimization checklist for spectrum data on QwtPlot, with huge data at high refresh periods

[Giacomo S. <gia...@el...>]

Thanks Uwe, great! Got it.

One more question, below:

El 15/5/25 a las 9:21 a. m., Uwe Rathmann via qwt-interest escribió:
> Hi Giacomo,
>
>> To perform what you are suggesting, do I have all the tools within 
>> Qwt ? (QwtPointMapper) ...
>
> Yes, see https://qwt.sourceforge.io/class_qwt_point_mapper.html.
>
> You can also add some measurements ( QElapsedTimer ) to 
> QwtPlotCurve::drawLines - or overload it to be able to do the 
> debugging in your code:
>
> Maybe like this:
>
> void YourCurve::drawLines( QPainter* painter,
>     const QwtScaleMap& xMap, const QwtScaleMap& yMap,
>     const QRectF& canvasRect, int from, int to ) const override
> {
>    QwtPointMapper mapper;
>
>    mapper.setFlag( QwtPointMapper::WeedOutIntermediatePoints, true );
>    mapper.setBoundingRect( canvasRect );
>
>    QElapsedTimer timer;
>    timer.start();
>
>    const auto polyline =
>        mapper.toPolygon( xMap, yMap, data(), from, to );
>
>    qDebug() << timer.restart() << data()->size() << polyline.size();
>
>    painter->drawPolyline( polyline );
>
>    qDebug() << timer.elapsed()
> }
>
> Note, that the code above does not do any polygon clipping. If you 
> know that all samples are inside the canvas boundaries it should be 
> disabled.

You mean enable clipping if samples outside the canvas and disable 
clipping if all samples are inside?

I assume that samples inside canvas is equivalent to axis scales wide 
enough to contain all curves' points.

With regards

Giacomo.

>
> HTH,
> Uwe
>
>
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest

Re: optimization checklist for spectrum data on QwtPlot, with huge data at high refresh periods

[Uwe R. <Uwe...@ti...>]

Hi Giacomo,

> To perform what you are suggesting, do I have all the tools within Qwt ? 
> (QwtPointMapper) ...

Yes, see https://qwt.sourceforge.io/class_qwt_point_mapper.html.

You can also add some measurements ( QElapsedTimer ) to 
QwtPlotCurve::drawLines - or overload it to be able to do the debugging 
in your code:

Maybe like this:

void YourCurve::drawLines( QPainter* painter,
     const QwtScaleMap& xMap, const QwtScaleMap& yMap,
     const QRectF& canvasRect, int from, int to ) const override
{
    QwtPointMapper mapper;

    mapper.setFlag( QwtPointMapper::WeedOutIntermediatePoints, true );
    mapper.setBoundingRect( canvasRect );

    QElapsedTimer timer;
    timer.start();

    const auto polyline =
        mapper.toPolygon( xMap, yMap, data(), from, to );

    qDebug() << timer.restart() << data()->size() << polyline.size();

    painter->drawPolyline( polyline );

    qDebug() << timer.elapsed()
}

Note, that the code above does not do any polygon clipping. If you know 
that all samples are inside the canvas boundaries it should be disabled.

HTH,
Uwe

Re: optimization checklist for spectrum data on QwtPlot, with huge data at high refresh periods

[Giacomo S <gia...@el...>]

Hi Uwe and thanks very much for your time,

To perform what you are suggesting, do I have all the tools within Qwt ? 
(QwtPointMapper) or are you implying I need to implement even more 
aggressive filtering by myself (or some external library)?

Some more questions follow :

On 5/14/25 6:08 PM, Uwe Rathmann via qwt-interest wrote:
> Hi Giacomo,
>
> when using FilterPointAggressive you will have a maximum of 3 vertical 
> lines per pixel and an additional horizontal line to jump to the 
> following pixel.
>
> The performance for rendering these lines depends on the paint engine 
> below - xcb or opengl should be using the GPU.
>
> So the very first thing I would do is to find out what type of refresh 
> rate you can achieve for a limited number of points that is good 
> enough to create a "4 points for each pixel" scenario ( note, that the 
> amplitude of the vertical lines matters ).
You mean, for example if my plot is 1000 pixels wide, test with ~4000 
points (4 × 1000).
>
> In case the performance for such a test scenario is good enough I 
> would continue with tests with QwtPointMapper to find out how much 
> time is needed for the FilterPointAggressive algo and how much of the 
> render cycle is consumed there.

Ok, so you are suggesting to measure separately
1. how much time is lost in QwtPointMapper and
2. how much is lost in the rendering (how do I measure the rendering 
time by the way? Is A QElapsedTimer before and after replot()  enough?)


Do you advise to disable filterpointsAggressive flag in QwtPlotCurve and 
do that on data beforehand, for example:

QwtPointMapper mapper;
mapper.setFlag(QwtPointMapper::FilterPointsAggressive, true);
mapper.setBoundingRect(plot->canvas()->contentsRect());

QPolygonF reducedData;
reducedData = mapper.toPolygonF(data);

and then setData with the reducedData?

Much obliged

Giacomo

>
> Then continue with the other steps of the pipeline until it is 
> understood, where too much time gets lost.
>
> HTH,
> Uwe
>
>
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest

Re: optimization checklist for spectrum data on QwtPlot, with huge data at high refresh periods

[Uwe R. <Uwe...@ti...>]

Hi Giacomo,

when using FilterPointAggressive you will have a maximum of 3 vertical 
lines per pixel and an additional horizontal line to jump to the 
following pixel.

The performance for rendering these lines depends on the paint engine 
below - xcb or opengl should be using the GPU.

So the very first thing I would do is to find out what type of refresh 
rate you can achieve for a limited number of points that is good enough 
to create a "4 points for each pixel" scenario ( note, that the 
amplitude of the vertical lines matters ).

In case the performance for such a test scenario is good enough I would 
continue with tests with QwtPointMapper to find out how much time is 
needed for the FilterPointAggressive algo and how much of the render 
cycle is consumed there.

Then continue with the other steps of the pipeline until it is 
understood, where too much time gets lost.

HTH,
Uwe

optimization checklist for spectrum data on QwtPlot, with huge data at high refresh periods

[Giacomo S. <gia...@el...>]

Hello everyone.

In my application I need to display very large data on qwt plot curves

The number of points can vary from 100.000 to one million.

Refresh rates: 10 / 20 Hz or more.

What is the checklist to obtain the best performance (apart from 
"downsampling")

Here's my configuration:

- curve paint attributes: default or even FilterPointAggressive (reduces 
CPU)

- curve pen width 0

- canvas->setFrameStyle( QFrame::NoFrame | QFrame::Plain );

- canvas->setLineWidth( 1 );

- curve->setRenderHint(QwtPlotItem::RenderAntialiased, false);

- using   setData     (     QwtSeriesData< T > * series    )     on 
curves, with a custom implementation deriving from QwtSeriesData< 
QPointF > and  manually calculating boundingRect if needed

- using std::move every time new data is available in the form of 
std::vector<double>

- using  canvas()->replot and calling updateAxes only if one-of  
axisEnabled && axisAutoscale for each axis

   (in other words: not calling QwtPlot::replot() at every data update, 
I don't know whether there is any benefit or not doing this)

  - grid enabled with pen width 0

Is there any other valuable consideration I am missing?

With regards

Giacomo, ELETTRA Synchrotron Radiation Facility, Trieste, ITALY

Re: (adding ?) include paths to Qwt build

[Giacomo S. <gia...@el...>]

<div dir='auto'>thanks uwe.<div dir="auto">I further investigated on the topic.</div><div dir="auto">actually the way to go is to install the compiler and tools under the conda environment.</div><div dir="auto"><br></div><div dir="auto">at this point I can't figure out the proper way to tell qwt to use the conda-cpp compiler instead of g++.</div><div dir="auto"><br></div><div dir="auto">qmake6 QMAKE_CXX=&nbsp; QMAKE_CC= and the like do not have any effect, qmake still complains for missing g++</div><div dir="auto">compiler&nbsp;</div><div dir="auto">in other words, it seems impossible to override the g++ QMAKE_CXX value set in the qmake specs...&nbsp;</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 Apr 2025 09:53, Uwe Rathmann via qwt-interest &lt;qwt...@li...&gt; wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On 4/15/25 16:54, Giacomo S. wrote:</p>
<p dir="ltr">&gt; GL/gl.h not found.</p>
<p dir="ltr">Note, that this include is from a Qt header - so this should be an issue <br>
with your Qt setup !</p>
<p dir="ltr">&gt; Now, I solved the issue installing&#160; libgl-dev system-wide.</p>
<p dir="ltr">I'm not familiar with all details of Ubuntu but I guess there are Qt <br>
development packages that would have a dependency to libgl-dev.</p>
<p dir="ltr">&gt; Do I have to patch the .pro / .pri files? If so, which one is the most </p>
<p dir="ltr">As the dependency is an internal affair of Qt the Qwt project files <br>
would be the wrong place for such a fix.</p>
<p dir="ltr">When building Qt yourself I would expect its configure script to adjust <br>
the paths in your pro files. In case Qt has been installed as binary <br>
package you probably need to check yourself if it matches the <br>
dependencies provided by the opengl headers you want to use for building <br>
your application.</p>
<p dir="ltr">HTH,<br>
Uwe<br></p>
<p dir="ltr">_______________________________________________<br>
qwt-interest mailing list<br>
qwt...@li...<br>
https://lists.sourceforge.net/lists/listinfo/qwt-interest<br>
</p>
</blockquote></div><br></div>

Re: (adding ?) include paths to Qwt build

[Uwe R. <Uwe...@ti...>]

On 4/15/25 16:54, Giacomo S. wrote:

> GL/gl.h not found.

Note, that this include is from a Qt header - so this should be an issue 
with your Qt setup !

> Now, I solved the issue installing  libgl-dev system-wide.

I'm not familiar with all details of Ubuntu but I guess there are Qt 
development packages that would have a dependency to libgl-dev.

> Do I have to patch the .pro / .pri files? If so, which one is the most 

As the dependency is an internal affair of Qt the Qwt project files 
would be the wrong place for such a fix.

When building Qt yourself I would expect its configure script to adjust 
the paths in your pro files. In case Qt has been installed as binary 
package you probably need to check yourself if it matches the 
dependencies provided by the opengl headers you want to use for building 
your application.

HTH,
Uwe

(adding ?) include paths to Qwt build

[Giacomo S. <gia...@el...>]

Hello everyone.

Trying to build qwt 6.3.0 under a *conda* environment I found out that 
on an ubuntu system WITHOUT

libgl-dev

installed system-wide I get the error

GL/gl.h

not found.

Then I  conda installed

  conda-forge / mesa-libgl-devel-conda-x86_64

which provides the file

/path/to/conda/environment/usr/include/GL/gl.h

But the conda "system" path, in this case:

/path/to/conda/environment/usr/include

is not present in the include list.

Now, I solved the issue installing  libgl-dev system-wide.

Questions:

is it safe? (I may include /usr/include/GL/gl.h) which is incompatible 
with the libGLX.so under the conda environment /lib dir

Is it possible to explicitly include the conda environment include dirs 
BEFORE the system include dirs possibly brought in by qmake?

Do I have to patch the .pro / .pri files? If so, which one is the most 
suitable to add:
unix:INCLUDEPATH
and
unix:LIBS

?

With regards

Giacomo.

Re: Border Dist

[Uwe R. <Uwe...@ti...>]

On 11/12/24 15:47, Filipe Lopes wrote:

> What I want is to set the border distance to start = 0 and end = 0.

Maybe: plot->plotLayout()->setAlignCanvasToScales( true );

Uwe

Re: Border Dist

[Filipe L. <fil...@ho...>]

The first replot of my widget occurs when the widget is not yet visible. I create and initialize the widget before making it visible. During this first replot, the end of border dist is set to 2. Once I make the widget visible, the end of border dist remains at 2. However, during the next replot, the end of border dist is reset to 0. This causes a slight issue when the margin disappears.
I noticed that when a QwtPlot becomes visible, updateLayout() is called, but it seems that this isn't sufficient in my case.

I tried setting QwtScaleEngine::setMargins, but it didn’t solve the issue.

What I want is to set the border distance to start = 0 and end = 0.


De : Uwe Rathmann via qwt-interest <qwt...@li...>
Date : lundi, 11 novembre 2024 à 15:46
À : List for both Qwt users and developers <qwt...@li...>
Cc : Uwe Rathmann <Uwe...@ti...>
Objet : Re: Border Dist
On 11/8/24 16:46, Filipe Lopes wrote:

> However, if I call replot() after that, the border distance is reset
> to 0.0, and I don't know why.

Adjusting the border distance is part of the layout system, that
is executed by replot.

But what about:

     plot->axisWidget( ... )->setMinBorderDist( ... );

Then the distance will be your margins - beside the tick labels require
more space.

> ... the border distance is set to 0.2

The border distance is a margin in pixels - and 0.2 does not make much
sense then. Maybe QwtScaleEngine::setMargins is what you are looking for ?

HTH,
Uwe


_______________________________________________
qwt-interest mailing list
qwt...@li...
https://lists.sourceforge.net/lists/listinfo/qwt-interest

Re: Border Dist

[Uwe R. <Uwe...@ti...>]

On 11/8/24 16:46, Filipe Lopes wrote:

> However, if I call replot() after that, the border distance is reset 
> to 0.0, and I don't know why.

Adjusting the border distance is part of the layout system, that
is executed by replot.

But what about:

     plot->axisWidget( ... )->setMinBorderDist( ... );

Then the distance will be your margins - beside the tick labels require
more space.

> ... the border distance is set to 0.2

The border distance is a margin in pixels - and 0.2 does not make much
sense then. Maybe QwtScaleEngine::setMargins is what you are looking for ?

HTH,
Uwe

Border Dist

[Filipe L. <fil...@ho...>]

Hi everyone,

I hope you're all doing well. I'm currently working on a project where I'm plotting data using Qwt. However, I'm encountering an issue with the border distance of the Y-axis widget.
When I initialize my QwtPlot (before it's visible), the border distance is set to 0.2, causing a margin. When I make the plot visible, the margin is still there. However, if I call replot() after that, the border distance is reset to 0.0, and I don't know why.

I was wondering if anyone has encountered a similar issue before and could offer some advice on it ? Are there any specific techniques or settings that I should be aware of?

Any help or suggestions would be greatly appreciated. Thank you in advance for your time and assistance!

Best regards,

Re: How to selectively disable or remove out-of-bounds axis labels in QwtPlot without affecting axis behavior?

[Yash K. <yas...@sg...>]

Dear Uwe and Ларионов Даниил,

Dear Uwe and Ларионов Даниил,

Thank you both for your helpful responses. Ларионов, the CpuPlot comment you directed me to was exactly what I needed to stop the axes from jumping, and it worked perfectly. Uwe, I appreciate having such a note in the library, and I'm grateful for your guidance.

Thanks again to both of you for your support!

Best regards,
Yash Karpe

> On 10/21/2024 9:22 AM CEST Uwe Rathmann via qwt-interest <qwt...@li...> wrote:
> 
>  
> On 10/16/24 15:59, Yash Karpe via qwt-interest wrote:
> 
> > I have already tried overriding the /drawLabel()/ method in a custom 
> > /QwtScaleDraw/ class to skip drawing out-of-bounds labels, but the axis 
> > still behaves as if the labels exist.
> 
> What about overloading:
> 
>      virtual QwtText QwtAbstractScaleDraw::label( double ) const;
> 
> and returning an empty string.
> 
> Not 100% sure if this already good enough, but it affects the layout 
> code ( in opposite to suppressing rendering of the text only ).
> 
> HTH,
> Uwe
> 
> 
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest

Re: How to selectively disable or remove out-of-bounds axis labels in QwtPlot without affecting axis behavior?

[Uwe R. <Uwe...@ti...>]

On 10/16/24 15:59, Yash Karpe via qwt-interest wrote:

> I have already tried overriding the /drawLabel()/ method in a custom 
> /QwtScaleDraw/ class to skip drawing out-of-bounds labels, but the axis 
> still behaves as if the labels exist.

What about overloading:

     virtual QwtText QwtAbstractScaleDraw::label( double ) const;

and returning an empty string.

Not 100% sure if this already good enough, but it affects the layout 
code ( in opposite to suppressing rendering of the text only ).

HTH,
Uwe

Re: How to selectively disable or remove out-of-bounds axis labels in QwtPlot without affecting axis behavior?

[Ларионов Д. <scu...@ya...>]

This is a rather old issue. 

> Is there any method to fully disable or simplify the out-of-bounds labels so they don't affect the axis movement?

Check out the comment at
examples/cpuplot/CpuPlot.cpp:114
Since that workaround was done by the author himself, my guess at the answer to your question is "no".


> I am working on a project that uses QwtPlot for plotting multiple graphs, and I'm encountering an issue with the x-axis labels. When panning the graph, the axis labels near the edges sometimes get stuck due to their size (especially labels with floating-point values). This causes a small delay before the axis continues moving, which results in a mismatch between my common axis and other axes that are hidden.
> 
> I want to prevent this behavior by either:
> 
> 2. Disabling or not drawing the labels that are outside the visible range (i.e., labels near the edges).
> 
> 4. Removing the floating-point precision from the labels that are near the edges, while keeping the axis behavior smooth.
> 
> I have already tried overriding the drawLabel() method in a custom QwtScaleDraw class to skip drawing out-of-bounds labels, but the axis still behaves as if the labels exist.
> 
> Here's the relevant part of my custom QwtScaleDraw class:
> 
> void CustomScaleDraw::drawLabel(QPainter *painter, double value) const override
> 
> {
> 
> QPointF labelPos = labelPosition(value);
> 
> // Skip drawing the label if it's out of bounds
> 
> if ((labelPos.x() < 0 || labelPos.x() > length() - 15) && orientation() == Qt::Horizontal)
> 
> {
> 
> return; // Skip drawing labels that are out of bounds
> 
> }
> 
> painter->save();
> 
> QFont labelFont(fontStyle, fontSize);
> 
> painter->setFont(labelFont);
> 
> painter->setPen(axisColor);
> 
> QwtScaleDraw::drawLabel(painter, value);
> 
> painter->restore();
> 
> }
> 
> Despite skipping the label drawing, the axis still behaves as if the labels exist, which causes the sticking behavior near the edges.
> 
> Attempted solutions:
> 
> * I tried disabling the labels using QwtAbstractScaleDraw::enableComponent(QwtAbstractScaleDraw::Labels, false) for out-of-bounds labels, but it disables labels globally, not selectively.
> 
> * I've considered modifying the transformation of the labels using labelTransformation(), but even then the axis gets stuck.
> 
> My goal is to:
> 
> * Either prevent the axis from considering the out-of-bounds labels at all.
> 
> * Or, remove the floating-point precision for labels near the edges to make them smaller and avoid the sticking behavior.
> 
> Is there any method to fully disable or simplify the out-of-bounds labels so they don't affect the axis movement?

How to selectively disable or remove out-of-bounds axis labels in QwtPlot without affecting axis behavior?

[Yash K. <yas...@sg...>]

I am working on a project that uses QwtPlot for plotting multiple graphs, and I'm encountering an issue with the x-axis labels. When panning the graph, the axis labels near the edges sometimes get stuck due to their size (especially labels with floating-point values). This causes a small delay before the axis continues moving, which results in a mismatch between my common axis and other axes that are hidden.
 
I want to prevent this behavior by either:
   1. Disabling or not drawing the labels that are outside the visible range (i.e., labels near the edges).
   2. Removing the floating-point precision from the labels that are near the edges, while keeping the axis behavior smooth.
I have already tried overriding the drawLabel() method in a custom QwtScaleDraw class to skip drawing out-of-bounds labels, but the axis still behaves as if the labels exist.
 
Here's the relevant part of my custom QwtScaleDraw class:
 
 
void CustomScaleDraw::drawLabel(QPainter *painter, double value) const override
{
QPointF labelPos = labelPosition(value);
// Skip drawing the label if it's out of bounds
if ((labelPos.x() < 0 || labelPos.x() > length() - 15) && orientation() == Qt::Horizontal)
{
return; // Skip drawing labels that are out of bounds
}
painter->save();
QFont labelFont(fontStyle, fontSize);
painter->setFont(labelFont);
painter->setPen(axisColor);
QwtScaleDraw::drawLabel(painter, value);
painter->restore();
}

Despite skipping the label drawing, the axis still behaves as if the labels exist, which causes the sticking behavior near the edges.
 
Attempted solutions:
    * I tried disabling the labels using QwtAbstractScaleDraw::enableComponent(QwtAbstractScaleDraw::Labels, false) for out-of-bounds labels, but it disables labels globally, not selectively.
    * I've considered modifying the transformation of the labels using labelTransformation(), but even then the axis gets stuck.
My goal is to:
    * Either prevent the axis from considering the out-of-bounds labels at all.
    * Or, remove the floating-point precision for labels near the edges to make them smaller and avoid the sticking behavior.
Is there any method to fully disable or simplify the out-of-bounds labels so they don't affect the axis movement?
 

Re: Problems printing largers plots

[Aslund <seb...@gm...>]

Hey Uwe

Thank for running the program.

That is strange. I wonder if it is a Windows issue.
I had this problem for many years. I usually handled it by reducing the
number of samples, but I always wanted a proper fix.

I tried the program myself before sending it and it failed on the bad
printing.

Regards
Sebastian


On Fri, 9 Aug 2024, 13:47 Uwe Rathmann, <Uwe...@ti...> wrote:

> Hi Sebastian,
>
> > I have made a minimal working example showing a good printing and bad
> > printing. It is made using Qt 6.5.1 and Qwt 6.2
>
> I tried your example using Qwt from the develop branch with Qt 6.7.2 on
> a Linux/Debian system.
>
> When printing to PDF I can't see the issue there ( see attached
> screenshots ) ?
>
> Uwe
>
>
>
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest
>

Re: Layout sizeHint weird behavior

[Giacomo S <gia...@el...>]

Actually, a call to replot() fixed the issue.

I don't know whether it's the best option or not. A simple updateAxes 
may be more lightweight.

Why is the default setting of QwtScaleWidget 0-100 if a plot shows 0 - 
1000 when it is actually drawn?



On 8/9/24 2:13 PM, Uwe Rathmann wrote:
> On 8/8/24 10:10, Giacomo S wrote:
>
>> Well, printing the list of major ticks, *before* the default scale 
>> bounds are set from 0 to 1000 with 6 major ticks, this is what I get:
>>
>> QwtPlot.sizeHint: Y axis ticks: 0.000000, 10.000000, 20.000000, 
>> 30.000000, 40.000000, 50.000000, 60.000000, 70.000000, 80.000000, 
>> 90.000000, 100.000000,
>
> The default setting of QwtScaleWidget is [0,100].
>
>> I think there is something (temporarily) wrong in the initialization 
>> of the scales.
>
> Well the size hints of the plot depends on the hints from the scales 
> and the hint of a scale depend on its ticks. The ticks are set in 
> QwtPlot::updateAxes, what can be called explicitly or implicitly from 
> replot. So yes - the size hint of the plot is not updated before 
> updateAxes has been called.
>
> But note, that any QWidget has to indicate changes of its size hint by 
> posting a QEvent::LayoutRequest. This might be done by 
> QWidget::updateGeometry() or manually like in QwtPlot::replot.
>
> When working with Qt layouts the event should be handled by them. If 
> not you could implement an event handler in the parent of your plot 
> widget.
>
> HTH,
> Uwe
>
>
>
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest

Re: Layout sizeHint weird behavior

[Uwe R. <Uwe...@ti...>]

On 8/8/24 10:10, Giacomo S wrote:

> Well, printing the list of major ticks, *before* the default scale 
> bounds are set from 0 to 1000 with 6 major ticks, this is what I get:
> 
> QwtPlot.sizeHint: Y axis ticks: 0.000000, 10.000000, 20.000000, 
> 30.000000, 40.000000, 50.000000, 60.000000, 70.000000, 80.000000, 
> 90.000000, 100.000000,

The default setting of QwtScaleWidget is [0,100].

> I think there is something (temporarily) wrong in the initialization of 
> the scales.

Well the size hints of the plot depends on the hints from the scales and 
the hint of a scale depend on its ticks. The ticks are set in 
QwtPlot::updateAxes, what can be called explicitly or implicitly from 
replot. So yes - the size hint of the plot is not updated before 
updateAxes has been called.

But note, that any QWidget has to indicate changes of its size hint by 
posting a QEvent::LayoutRequest. This might be done by 
QWidget::updateGeometry() or manually like in QwtPlot::replot.

When working with Qt layouts the event should be handled by them. If not 
you could implement an event handler in the parent of your plot widget.

HTH,
Uwe

Re: Qwt 6.3.0 + qt6 = pkgconfig for Qt5

[Uwe R. <Uwe...@ti...>]

On 8/8/24 10:13, Giacomo S wrote:

> building qwt 6.3.0 with qt-6, still results in a pkgconfig file linked 
> to Qt5 libs.

Indeed see: 
https://sourceforge.net/p/qwt/git/ci/develop/tree/src/src.pro#l82

Could you please come up with a "greaterThan(QT_MAJOR_VERSION, 5)" patch ?

Uwe

Re: Problems printing largers plots

[Uwe R. <Uwe...@ti...>]

Hi Sebastian,

> I have made a minimal working example showing a good printing and bad 
> printing. It is made using Qt 6.5.1 and Qwt 6.2

I tried your example using Qwt from the develop branch with Qt 6.7.2 on 
a Linux/Debian system.

When printing to PDF I can't see the issue there ( see attached 
screenshots ) ?

Uwe

Qwt 6.3.0 + qt6 = pkgconfig for Qt5

[Giacomo S <gia...@el...>]

Dear Qwt users and developers,

building qwt 6.3.0 with qt-6, still results in a pkgconfig file linked 
to Qt5 libs.

I remember this was something that had  already been discussed, and I 
expected it to be fixed in 6.3.0.

Apologies if I am missing something.

With kindest regards

Layout sizeHint weird behavior

[Giacomo S <gia...@el...>]

Dear all,

After subclassing QwtPlot, before any additional setting, the plots have 
a big sizeHint(), which causes three of them in a vertical layout to 
resize the application well out of the screen.

While digging into QwtPlot sources (qwtplot.cpp, sizeHint() ), i placed 
some debug prints in order to understand what was going on.

It turns out that the size hint is calculated according to the number of 
major ticks, which is multiplied by 40 in order to reserve a reasonable 
size for the plot.

Well, printing the list of major ticks, *before* the default scale 
bounds are set from 0 to 1000 with 6 major ticks, this is what I get:

QwtPlot.sizeHint: Y axis ticks: 0.000000, 10.000000, 20.000000, 
30.000000, 40.000000, 50.000000, 60.000000, 70.000000, 80.000000, 
90.000000, 100.000000,
QwtPlot.sizeHint: X axis 2 dh 174 majCnt = 11 hDiff 174

There are 11 major ticks, 0, 10, 20, ..., 100.

I think there is something (temporarily) wrong in the initialization of 
the scales.

It is indeed expected that the major ticks are consistent with the 0 - 
1000 bounds, 6 major ticks, from the very beginning to the end of the 
initialization.

The size issue doesn't always happen. I guess it happens depending on 
the instant when the plots are arranged in the layout. In the cases 
where they are laid out "later", their size is reasonable.

With regards

Giacomo

Re: Problems printing largers plots

[Aslund <seb...@gm...>]

Hello Uwe

A plot with 63615 points prints fine, but another with 223767 points gives
these errors as shown in the previous email.

I have made a minimal working example showing a good printing and bad
printing. It is made using Qt 6.5.1 and Qwt 6.2
https://drive.google.com/file/d/1VrOCEK4DkcCy3blcybLYP5-8U7TUmxoQ/view?usp=sharing

Kind regards
Sebastian Aslund

On Thu, 1 Aug 2024 at 17:04, Uwe Rathmann <Uwe...@ti...> wrote:

> On 7/31/24 11:51, Aslund wrote:
>
> > I have had for a long time an issue with printing larger Qwt plots.
> > Is there any solution to this or am I setting something wrong up?
>
> Code looks o.k. to me.
>
> What do you mean by "larger" in this context - a curve with many points ?
>
> I'm wondering if the problem is related to your system ( f.e device
> pixel ratio ) or your specific plot: do you have the problem with one of
> the Qwt examples ?
>
> Uwe
>
>
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest
>

Re: Problems printing largers plots

[Uwe R. <Uwe...@ti...>]

On 7/31/24 11:51, Aslund wrote:

> I have had for a long time an issue with printing larger Qwt plots.
> Is there any solution to this or am I setting something wrong up?

Code looks o.k. to me.

What do you mean by "larger" in this context - a curve with many points ?

I'm wondering if the problem is related to your system ( f.e device
pixel ratio ) or your specific plot: do you have the problem with one of
the Qwt examples ?

Uwe