🍂if I'm ever invited back to my alma mater's CS program to talk, I'm going to encourage them to learn as many tools and paradigms as possible, not for marketability reasons but because it expands your shit-talking horizons
related: did you know that a QtQuick.Controls BusyIndicator eats literally all the CPU time in the universe just to show a spinning animation
it turns out that the thing is rebuilding its part of the scene graph every frame, but all it's doing is updating some transforms? and I don't understand why that isn't all done on the GPU as shader programs; you don't need advanced shader features to send in a time uniform to spin things around
gabby kar@ninjawedding yyyyyeah, that's also, like,... that doesn't even sound consistent with how most of .Controls work, iiiii thought?
but i could be mixing that up with Controls2 🤔
@gdkar well, they all participate in the Qt scene graph, so I think that bit's consistent. it does seem to be doing a lot of CPU work for something that shouldn't need that much CPU time, though
@gdkar also, yeah, I should clarify -- I'm using QtQuick.Controls 2.0's BusyIndicator
@ninjawedding hmmmm....
@gdkar I thought so too, but then I saw https://code.woboq.org/qt5/qtquickcontrols2/src/imports/controls/qquickdefaultbusyindicator.cpp.html#_ZN30QQuickDefaultBusyIndicatorNode4syncEP10QQuickItem
I guess that's optimized by the polishing step, though I'm not quite sure to what. However, it might turn out that this code isn't even invoked at all, because the Imagine QtQuick.Controls2 theme has a very different-looking implementation based on AnimatedImage
I guess that's optimized by the polishing step, though I'm not quite sure to what. However, it might turn out that this code isn't even invoked at all, because the Imagine QtQuick.Controls2 theme has a very different-looking implementation based on AnimatedImage
@ninjawedding ahhhh, right, the Controls2 approach makes that highly theme dependant, huh.
@gdkar yep
unfortunately I don't think the QML profiler has access to enough data to show this issue. It'll show that the GUI thread is continuously busy running animations, but not what's animating. the per-line cost distribution doesn't implicate BusyIndicator at all, because it only shows e.g. binding and creation costs, and those are very low
unfortunately I don't think the QML profiler has access to enough data to show this issue. It'll show that the GUI thread is continuously busy running animations, but not what's animating. the per-line cost distribution doesn't implicate BusyIndicator at all, because it only shows e.g. binding and creation costs, and those are very low
@gdkar having said that, it's really easy to demonstrate by adding two BusyIndicators to a scene and then running top
@ninjawedding yeah, iiiii thought at least some of that was shader + parameter, tho? ( so it'd be literally one scene graph construction event at load? )
if it's not, it'd be pretty trivial to spin your own as a ShaderEffect or equiv, but.... eugh you really shouldn't have to.