Closed mottosso closed 4 years ago
The more critical problem is that it did not remove the event filter when the QML window is closed.
I did not know that event filter will not be removed when the tool window is closed, perhaps I should first implement the remove call.
Sorry about that :(
One possible hard way to go to get ride of event filter completely and maintain reasonable UX is to provide a master publish window, which will interact like Adobe Media Encoder.
A master window that able to dock every QML window. What do you think ?
That's true, if it can remain active only when QML is running, then that's be an OK performance tradeoff. Simply close the window, and you're back to normal.
I think if this were the case, then we could stick with an event filter and wouldn't have to worry about anything more complex.
I think if this were the case, then we could stick with an event filter and wouldn't have to worry about anything more complex.
This stopped me from pushing a snow ball :)
I will patch this one up ASAP.
Thanks @davidlatwe, loving your pro-activity. :)
@davidlatwe @mottosso was this issue resolved with https://github.com/davidlatwe/pyblish-qml/commit/2580f01646feb58658b04c951901fbd47de13288 ?
Looks like it, I think you can confirm by closing QML and seeing whether it prints that message.
Can confirm that message "The eventFilter of pyblish-qml has been removed."
gets print every time it closed here.
Solved!
This is a critical run-time performance fault, the event filter is called on every event passed through Qt - e.g. mouse move, draw, layout updates - affecting overall interactivity including playback.
The issue is that Qt is a C++ framework with tens of thousands of events per second, which isn't normally a problem. But putting an event filter on the main window means filtering each of those events through Python; effectively creating a bottleneck.
You can confirm this for yourself.
Run this, dolly the camera, and then inspect
count
.Here's what it said for me.
That's 7,100 calls to Python unrelated to actually using the viewport. They're unnecessary calls, needless overhead. To animators struggling with rig performance, this can drop performance from 24 to 22 fps which is enough to lose real-time.