[Qt5-feedback] 400000 chips example in QML?

[Kishore]

On Thursday 12 May 2011 7:37:49 PM Samuel Rødal wrote:
> On 05/12/2011 12:11 PM, ext Kishore wrote:
> > On Thursday 12 May 2011 2:38:42 PM Samuel Rødal wrote:
> >> On 05/12/2011 10:55 AM, ext Kishore Jonnalagadda wrote:
> >>> As was asked in the blog
> >>> http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/.
> >>> 
> >>> I would like to know if QML can scale well enough. It seemed that
> >>> QGraphicsView used QGraphicsItems as they were much lighter than using
> >>> QWidget. But with QML each item will again be a QObject. Does this not
> >>> add too much overhead? Take the example of the 400000 chips for
> >>> reference.
> >>> 
> >>> --
> >>> Cheers,
> >>> Kishore
> >> 
> >> QML isn't really meant for such use-cases (visualization of large data
> >> sets). The right way of doing this would be to use scene graph or OpenGL
> >> directly (and you'd get much better performance than in the 40000 chips
> >> demo).
> > 
> > So this demo in Qt5 would use C++ code for the UI and not QML? So then
> > there really are a lot of use cases where QML is not entirely suitable.
> > Right?
> > 
> > Now, would the coding in c++ with scene graph (Sorry, i don't know much
> > about the technology) would be the Qt5 way? Does it replace QGV?
> > 
> > Of course, OpenGL is an alternative just as it is today. But would Qt
> > provide a way of doing it like it now does with QGV or is direct OpenGL
> > the "recommended" way?
> 
> QML main focus is application UIs, but that doesn't mean it's a good fit
> for all UIs. For example, the 3D model editor in Maya is also a user
> interface, one which requires a fully specialized solution. I would say
> the same for other UIs where you need to do visual manipulation of huge
> data-sets.
> 
> For UIs that fall outside of the scope of QML, QGraphicsView is still an
> option, as is using raw OpenGL with the enablers that Qt provides
> (QGLFramebufferObject, QGLShaderProgram, etc), or the higher level
> Qt/3D, as well as other scene graph APIs like OGRE and OpenSceneGraph.
> The new Qt scene graph is also an option, but it's designed more with
> the use cases of QtQuick 2.0 in mind and doesn't have a convenience
> layer like QGraphicsView.
> 
> I don't think anyone is saying that QML is the way _all_ graphics should
> be done in the future.

Thanks. That clears the air a bit for me. In summary,

1) Anything that is currently a QWidget can become a QML object.
2) Applications that currently required to use QGraphicsItems (Like Umbrello, 
semantik etc) should continue to use QGV for that main widget and export it 
for inclusion in a QML "shell".
3) More 3D intensive apps should choose to use OpenGL (or Qt3D) or third party 
libraries as you have mentioned for implementing that main QWidget as 
mentioned in 2.

That's broadly the way i see it. Looking forward to QtComponents!
-- 
Cheers!
Kishore

ps: With QtMobility's Maps and Navigation API, i was wondering how efficient it 
would be to place hundreds of QGeoMapObjects (which are QObjects) on a map.