[Interest] To QML or not to QML...
sivan at omniqueue.com
Tue Mar 6 12:21:58 CET 2012
On Mon, Mar 5, 2012 at 7:39 PM, BRM <bm_witness at yahoo.com> wrote:
> As I have not yet touched QML, and there are many on this list who have, what you recommend?
> Would it be worth trying to do this in QML - either #2 or #3 - or should I just stick to #1?
You could try and use pure QML (e.g. have QML elements of a Point and
rest of your entities) abstraction and do a test run if speed is
what's important in populating thousands of items.
I would guess that drawing inside a QML View will behave and have the
same constraints as drawing inside a QWidget, perhaps with some
performance difference depending on the complexity of your drawing if
you stick to high level item (complex shapes as custom elements
themselves) but if you implement it yourself you might need to
re-implement a translation layer from highlevel -> geomtric shapes ->
back to low level drawing and and profiling and perfecting your QML
should prove much more beneficial.
QML abstraction will give you the enormous (in my experience) benefit
of close to effortless reusable components, and making the "drawing"
process close to 'code-free' , real nicety when you add more overlays
and detail perhaps in the future, or base more advanced display items
on what you already have, or use this overlaying and layers in many
other apps you might want to develop further (again, in *my*
experience, with less hassle than using QWidget code) , and be able to
use QML's cool fluidity and relatively easy to achieve display and
device scaling and fit, and.. and... (well you got it, I love QML ;).
Eventually, I've seen people here make their QML become very
performant with the suitable know how and I'm sure you could find
help if you run into issues. The important thing is to try and
experiment with your data set before you invest into switching
technologies, a good approach to follow before any major rewrite!
Hope this helps,
More information about the Interest