QtCS2024 How to hate QML
Jump to navigation
Jump to search
Session Summary
Session Owners
Notes
- Should we find a different language that doesn't need QObject and JavaScript
- We're not all in on JS, we're not using the latest. Can't use NPM modules out of the box
- TypeScript was considered at some point
- Lack of modern JS means no support for NodeJS modules
- The NPM ecosystem duplicates things we already have in Qt, should expose the Qt stuff
- Could we make improvements to QObject to reduce memory overhead?
- Advantage of QObject is that we get all of Qt (and C++) integrated, since Qt builds on QObject
- A problem today is exposing data to QML
- Is the user experience (quick iteration, easy to use) maintained when doing the qml modules or compilation improvements
- A new language will be a third way to create UIs with Qt. Will not be able to take advantage of existing code
- QObject and JS _is_ QML, and that's a tradeoff we've made. Throwing out that is crazy
- The garbage collector can be improved in many ways
- Even with QML compiled to C++ we still need a GC
- Breaking the identity of our existing product (QObject/JS) is not going to bring us anywhere
- Can we improve things within the system constraints
- Custom QObject allocator, allocating private along with or as part of public
- Is the QObject size (144 bytes) really an issue? A 1mil app would still be 144mb, well within modern system memory
- Can we relieve memory pressure by ensuring the UI isn't loaded all at once
- We have Loader, not without its own set of problems
- Could have memory issues in other places, e.g. RHI
- Large glyph caches, uploading large images to blit subrect
- As framework engineer you only see the unhappy people.
- Are we optimizing for the unhappy few, without taking our happy users into account?
- Memory issues can be caused by user misusing e.g. delegates
- Another common complaint is HW acceleration driver issues