[Qt5-feedback] QML-related wishlist
Jason Kinzer
jmkinzer at gmail.com
Thu May 12 02:41:03 CEST 2011
Hi,
I wanted to throw my hat, erm wish-list, into the ring:
1 - Reduce QML memory overhead (important)
I would like to see this replace most of my uses for QGV. However, an issue
I have is that QObject is pretty fat, and QDeclarativeItem even more so. In
the cases for QGV where today I have huge numbers of items I can always use
the non QObject-based subclasses. For QML however, I appear to be stuck. It
would be wonderful if the declarative item could be refactored a la' QGV
into a lighter-weight base class that can be used if no events are required,
and heavier ones based on QObject otherwise. (And yeah, I know the initial
use-cases for QML specifically talked about reducing the item counts, but as
we're talking about ideally moving entirely to a QML-based frontend, I echo
comments some others have noted: let's see the 'chips' example in QML!).
2 - Improve QML performance for 'trivial' expressions (less important)
I've noticed there appear to be 2 engines used in QML (at least when I dove
into the code a few months back): the standard JSC engine, and then a
'fast-path' interpreter for very simple expressions (e.g. 0+1). This is nice
because from my experimentation in such simple cases the overhead of
invoking the JS engine far exceeds the time required to compute the
expression. However, my annoyance is that the current fast path is very,
very limited and it's incredibly easy to break it so that it reverts back to
the primary engine. My point: it would be great if this fast path were
improved (tho I'm not sure what new tradeoffs V8 introduces... maybe the
invocation overhead will be lower?)
3 - Provide abstraction layer for the QML engine binding (pie-in-the-sky)
I understand this team's desire to focus 100% on Javascript. However, what I
would love is for QML to expose a service provider interface that provides
all the calls/callbacks required a scripting engine. Such an SPI would allow
the community to introduce bindings for other languages. And yeah, I
understand there is then still the editor issue - ideally QT Creator would
also have an interface factored out for it's QML editor so we can introduce
QML editors that accept the syntax for other languages.
Thanks
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110511/7eabcdb9/attachment.html
More information about the Qt5-feedback
mailing list