Speed problem dragging points

In my project I have to draw a line with mouse.
To do this I have take some code slice from event_filter example in qwt source dir.
It works quite well if the window is "little", but it become too slow if I maximize the windows.
This issue is present also in the event_filter example, I have also have a screencast.
I hope it is not an issue of qwt, and I wonder how to speed up it

best regards
Max

Quote:

---

Originally Posted by mastupristi

To do this I have take some code slice from event_filter example in qwt source dir.

---

In this example you have replots while moving the point, what is o.k. for the example, but for plots with some content this should be avoided. A better approach is to translate the part that needs to be dragged into a QwtWidgetOverlay when being selected and retranslate it to a plot item when being released The itemeditor example shows how to do it - also QwtPlotPicker/QwtPlotZoomer use this a widget overlay for the rubberband.

Quote:

---

Originally Posted by mastupristi

It works quite well if the window is "little", but it become too slow if I maximize the windows.

---

I can't confirm this effect on my system and I don't see any reason why this should happen - at least, when you don't use a remote desktop.
But without knowing more detail about your environment it is hard to say any useful. But in general, when speaking about remote desktops and X11 I recommend to stay with Qt4 and the X11 paint engine ( what also offers hardware acceleration ).

But as a first step I recommend to play with the itemeditor example ( dragging the items with the mouse ). When working with remote desktops the mask mode ( see the combo box in the top left corner ) might have an effect.

Uwe

I have simplified as much as possible the event_filter example.
Attachment 11916
my purpose is to understand how this works, and then apply the overlay.
I have some questions, also unrelated to this issue.

but first of all I have to take a look deeply to the itemeditor example, and then I can try to apply overlay this example and the to my project.
Do you have any suggestion to make me get my goal quickly?

best regards
Max

Quote:

---

Originally Posted by mastupristi

Do you have any suggestion to make me get my goal quickly?

---

First of all you have to find out the reason for the bad performance - your code works without any problems on my box.

So what Qt version, which operating system, which hardware, is it a remote desktop ...

Uwe

I use xubuntu 16.04 with official qt pakages: qt 5.5.1, qwt 6.1.2.
The hw is an Intel i7 970, nVidia 460, 12gb RAM

Best regards
Max

Sounds like a powerful system - all I can imagine, that might explain the video is when your X11 is totally misconfigured.

Uwe

My computer is six years old, not a recent one, but it is still quite powerfull.
I'll take a look to x11 config. Until now I trust ubuntu to configure automagically X.
Anyway, the itemeditor example is fast enough also in full screen mode, and zoomed to have bigger items.

Best regards
Max

I spent some time investigating X11 config, I installed the new nVidia proprietary driver, I have tested the performance with x11perf. Nothing seems wrong. But the event_filter example was still slow.

So I decide to have a deeper look to itemeditor example to make event_filter use overlay.

The result is here:
Attachment 11919
It is definitely improvable, as coding style, as class usage, but it is fast enough also in fullscreen.
Can I have your opinion about it?

I also have a question on itemeditor example.

about eventFilter method in Editor class:

Code:

---

bool Editor::eventFilter( QObject* object, QEvent* event )
{
    QwtPlot *plot = qobject_cast<QwtPlot *>( parent() );
    if ( plot && object == plot->canvas() )
    {
        switch( event->type() )
        {
            case QEvent::MouseButtonPress:
            {
                const QMouseEvent* mouseEvent =
                    dynamic_cast<QMouseEvent* >( event );
 
                if ( d_overlay == NULL && 
                    mouseEvent->button() == Qt::LeftButton  )
                {
                    const bool accepted = pressed( mouseEvent->pos() );
                    if ( accepted )
                    {
                        d_overlay = new Overlay( plot->canvas(), this );
 
                        d_overlay->updateOverlay();
                        d_overlay->show();
                    }
                }
 
                break;
            }
            case QEvent::MouseMove:
            {
                if ( d_overlay )
                {
                    const QMouseEvent* mouseEvent =
                        dynamic_cast< QMouseEvent* >( event );
 
                    const bool accepted = moved( mouseEvent->pos() );
                    if ( accepted )
                        d_overlay->updateOverlay();
                }
 
                break;
            }
            case QEvent::MouseButtonRelease:
            {
                const QMouseEvent* mouseEvent =
                    static_cast<QMouseEvent* >( event );
 
                if ( d_overlay && mouseEvent->button() == Qt::LeftButton )
                {
                    released( mouseEvent->pos() );
 
                    delete d_overlay;
                    d_overlay = NULL;
                }
 
                break;
            }
            default:
                break;
        }
 
        return false;
    }
 
    return QObject::eventFilter( object, event );
}

---

For every event in the switch, it return false (line 61). But in the QT documentation about QObject::eventFilter there is:

Quote:

---

In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.

---

In this case why return false instead of true, since the events are handled?

best regards
Max

There are 2 differences between what happens in the itemeditor and the event_filter example.

a) In the itemeditor example the content of the plot remains unchanged. So when the item is dragged the content can be restored from a pixmap cache without having to do a replot.
b) Depending on the Mask parameter, the pixels written to the graphics stack might be limited to the pixels, that are really changing.

As the event_filter has almost no content, the effect of a) should be no factor - for heavy plots it would be significant. So in your case I would expect, that b) is what you are suffering from.

In case of remote desktops it is obvious, that pushing a fullscreen image ( width * height * 4 ) over the network is slower than a smaller one. Here it might be worth to go back to Qt4 ( graphic system native ), what is much faster for vector graphics. But as you are not using a remote desktop it means, that flushing a RGB buffer is a horrible bottleneck - something that will hit you in many other situations as well.

Uwe