drag and drop disturbing rendering ..

[jajdoo]

i have a widget that renders 3d graphics (an OGRE widget, to be specific).

it i render a frame on paint event, and call update() on timer event, which i set to interval of 1 ms;

problem is when dragging items around. the fps drops dramatically (from ~900 to less than 15). i recon this happens because drag operation intervene with main application loop (yes? no? not precise?).

usually this isn't really a problem, but i want to drag and drop a material into the scene, and make the target mesh/submesh "flicker" to indicate its the current target.

question is, can i somehow go around this?

[wysota]

Do you really need 1000 frames per second? I'm sure 40 frames per second will be more than enough and it will put several times less strain on the machine.

[jajdoo]

its a material editor, not a game; i need higher fps as test material/shader performance. embedding it in Qt already took a lot of fps (the default win32 OGRE render window would typically render twice as fast on the same circumstances ).

it doesn't have to be perfect (or incredibly fast) but dropping to less than 15 fps because of a drag/drop ...
again, it wouldn't be a problem if i wasn't drag&drop a material to the render window; since the user needs to point the cursor to a specific mesh, it takes a few seconds, in which the fps gradually worsen, disturbing the operation's reactiveness..

[wysota]

its a material editor, not a game; i need higher fps as test material/shader performance.

I fail to see why you would want such frame rates. The performance is not representative since much strain is put on the CPU. If I wanted to test performance, I would discard the whole environment that might have influence on the test.

embedding it in Qt already took a lot of fps (the default win32 OGRE render window would typically render twice as fast on the same circumstances ).

With dragging something in the window?

it doesn't have to be perfect (or incredibly fast) but dropping to less than 15 fps because of a drag/drop ...

As far as I know this is caused by some malfunction (or weirdness) in handling mouse events on Windows. I've seen timers stall because of a pressed mouse button (or maybe the window was just not being refreshed).

again, it wouldn't be a problem if i wasn't drag&drop a material to the render window; since the user needs to point the cursor to a specific mesh, it takes a few seconds, in which the fps gradually worsen, disturbing the operation's reactiveness..

Try reducing the frame rate as suggested and see how it influences the dragging slowdown.

[jajdoo]

1. yes, i know its not representative, but it need to show relative performance to give the developer a hint of how the material is behaving before he deploys it to an application. (i think i'll also add an option to launch a regular OGRE render window with the current scene for true performance testing).
i found NVIDIA FX Composer lack of showing fps counter annoying when changing small values to test the effect they might have. i actually listened to my video card rumble when testing where it starts working hard on my cone stepping shader...

2. without dragging, the frame rate is about half of the same equivalent on a dedicated win32 window; when dragging, it drops to less than 15.

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

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..)

[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?

[wysota]

been searching for any bug topic containing " drag drop ";

I'd search for mouse events not for drag and drop.