QtCS2024 How to hate QML

Notes

• 

  Slides
• 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