4 ms·
> Widgets draw different types of graphical elements one after the other, changing states rapidly. Since OpenGL excels in rendering lots of data of the same typ
by zerr 3y ago
> Widgets draw different types of graphical elements one after the other, changing states rapidly. Since OpenGL excels in rendering lots of data of the same type, but is slow when changing states, this created a performance penalty for Qt Widgets applications.
Why does this not hinder QML to be GPU-accelerated? (Or any other GPU-accelerated UI such as WPF, Flutter)
- dist-epoch 3y agoOne reason is in QML/WPF you use data binding instead of directly setting widget state like in classic Qt. Data binding allows the runtime to batch and consolidate changes. Classic Qt also encourages a bad state handling programming style which is hard to optimize. Data binding fixes that and moves more of the responsibility to the framework.
- ptx 3y agoCouldn't the rendering still be batched? In Swing, for example, onDraw is invoked whenever Swing feels like it (and so could presumably be batched) regardless of when and how often the component's state is updated.
- ahartmetz 3y agoAll the drawing in QWidgets is done imperatively with QPainter. Converting immediate mode painting to retained mode painting is possible, I guess... but not easy and probably full of pitfalls. Also, performance is just fine (really good actually) in practice, at least on PC-class hardware. QPainter's backend is not quite as fast as Skia, but still fast.