QtCS2024 How to hate QML: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
==Notes==
==Notes==


* Presentation by Ulf <link here>
* [[File:QML QtCS2024.pdf|alt=Slides|thumb|Slides]]
* Should we find a different language that doesn't need QObject and JavaScript
* 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
** We're not all in on JS, we're not using the latest. Can't use NPM modules out of the box

Latest revision as of 13:22, 5 September 2024

Session Summary

Session Owners

Notes

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