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)