drag and drop disturbing rendering ..

[wysota]

3. so... the problem is windows itself?..

Hard to say. I don't know if this happens for non-Qt apps too. It could be a Windows+Qt combination.

4. about reducing the frame rate:
the base frame rate is dependent the frequency of the paint events. more paint event(smaller timer interval) = higher fps.
reducing it from once per 1 ms to once per 5 ms drops it from base ~900 to ~150, while having no effect on the drag&drop slowdown (still drops to less than 15).
funnily, moving the mouse cursor frantically around the render window causes an increase in frame rate; i guess because it forces an update (or something..)

So it seems the slowdown doesn't depend on how busy the application is. I have a certain opinion about what is going on here. I think events are delivered fine and the problem is with redrawing the canvas while mouse events are delivered. Probably if you forget the number of repaints and focus on the number of update calls per second you would get your 900 fps. If I were you I would contact the Trolls about it, I'm sure they have encountered the behaviour many times and certainly have a theory (and maybe a workaround) about it.

[jajdoo]

I think events are delivered fine and the problem is with redrawing the canvas while mouse events are delivered.

not sure;
i added update whenever any event is delivered like so:

...
    installEventFilter( this );
...
bool polly::OgreWidget::event(QEvent *e)
{
    update();
    return QWidget::event(e);
}
 
 
bool polly::OgreWidget::eventFilter(QObject *o, QEvent *e)
{
    update();
    return QWidget::eventFilter(o,e);
}

...
    installEventFilter( this );
...
bool polly::OgreWidget::event(QEvent *e)
{
    update();
    return QWidget::event(e);
}


bool polly::OgreWidget::eventFilter(QObject *o, QEvent *e)
{
    update();
    return QWidget::eventFilter(o,e);
}

To copy to clipboard, switch view to plain text mode 

while my frame rate at idle improved (to ~1400), when drag is not moving it drops back to <15


reading this:
http://doc.qt.nokia.com/4.6/dnd.html

i found this comment:
"Although the user may take some time to complete the dragging operation, as far as the application is concerned the exec() function is a blocking function that returns with one of several values. These indicate how the operation ended, and are described in more detail below."

can this have something to do with it?

[wysota]

If paint events are not delievered then calling update() won't do anything. How do you calculate fps anyway?

can this have something to do with it?

No.

[jajdoo]

OGRE calculates fps internally, i just pass it to an lcd.

[wysota]

But it calculates it based on what?

[jajdoo]

i'm pretty sure it checks intervals between frames.

a slowdown is noticeable however, its not just not updating the fps correctly (if thats where you're heading)

[wysota]

No, that's not where I am heading. Never mind.

[jajdoo]

so.. anyone got some leads for me? should i really contact trolltech about it?

[tbscope]

How do you perform the drawing while drag and dropping?
You say you want to drag and drop a material onto a wireframe and indicate which part of the wireframe the mouse is over?
Is it possible that the code to do these calculations and painting is degrading performance?

[jajdoo]

was my initial thought too, but nay.
two reasons:
1. the scene query (as it is called) is a fast operation; i do it in various areas in the program with far less aggressive slowdown with continuous (per event) querying.
the scene query constructs a ray (a finite line) pointing from the camera's viewport the a direction calculated using mouse pointer's x&y and widget's x&y, then performs a search using an octree and some calculations. i ask the query which entity on the scene it hit and where, and ask the corresponding sub-mesh on the entity to change its material.

2. the drag&drop will cause the same slowdown even if the drag haven't even left its own widget; again, if the mouse is idle the slowdown is far greater than if the mouse moves. i query only on dragMove - also tried to lock dragMove querying to work only after dragEnter with correct mime data, to no effect.

in short: when the mouse move more (=more queries) the frame rate goes up, which means the querying isn't responsible.

the drawing is supposed to act the same when dragging - it should respond to the timer event (or at least, the update call should)

[wysota]

I'm still convinced this is caused by how mouse events affect other events on Qt+Windows combination. Did you search the bug tracker for similar issues?

[jajdoo]

been searching for any bug topic containing " drag drop "; haven't found anything yet, still looking.

i made a little test though, dunno if it helps either way: when dragging initiated and mouse is idle, the program's CPU usage drops from 50% to barely 1%.. does this move us anywhere?