Hello guys In my old mobile gaming programming times I was solving similar issues by loading single very big image and making small images to just refer to different parts of that big image. That's quite standard technique for 2D gaming - loading many sprites takes time on all systems.
That is probably impossible if you go for pure QML, but if you are ready to experiment with QmlCanvas and/or with trying to implement your own image providers that would provide sprites from the single huge image, that could help. Guarantees quite some headache though. BR, Artem. On Sep 29, 2011, at 10:39 PM, Pelle Johnsen wrote: > Hi again, > > You are right in that you don't need to specify async for network images > (sorry for not realizing that). In our tests we however found that it was not > loading the image data itself that was taking time, but creating the > QPixmaps, and because of QPixmap's limitation that can only be done in the > main ui thread - which then blocks the whole ui :( I don't know if there has > been improvements to this in 4.8, but it is a fundamental issue that QML > Image items use QPixmap, and these can ONLY be created in the main ui thread. > > I would guess QtQuick 2.0 would remedy this by not using QPixmaps, but OpenGL > textures instead for QML Image. > > -Pelle > > On Thu, Sep 29, 2011 at 9:09 PM, Artem Marchenko <artem.marche...@gmail.com> > wrote: > Hmm, Pelle > > Documentation tells that asynchronous works only with local filesystem, I am > not sure if resource file counts as local filesystem - > http://doc.qt.nokia.com/4.7-snapshot/qml-image.html#asynchronous-prop > > It probably won't help, but if I was desperate I would have tried deploying > images to file system and not to resource file and then tried asynchronous > property. > > Best regards, > Artem. > >
_______________________________________________ Qt-qml mailing list Qt-qml@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-qml
