> On 12 Feb 2015, at 18:03, Gunnar Roth <gunnar.r...@gmx.de> wrote: > > Hi, > after downloading it to my cell phone and picking it with usb connection, i > was finally able to read pdf document. > I am curious what the unit of the x-axis is in your diagrams, i fugure higher > is better, but what is measured there?
Hi Gunnar :) The x-axis is Qt version, did you perhaps mean y-axis? :) From my original mail: <snip> How the benchmark works is that the it tries to figure out how many operations of a given type is possible each frame (not per second) while sustaining a perfect 60 fps (or whatever other fps you target). For these numbers, we’re looking at delegation creation and destruction. You can look at the content of each specific benchmark here: https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation <https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation>. </snip> > IMO QuickItemText is too complicated for the simple case, which is > "displaying a single line of plain text of about 15 characters", as this is > the most common case in a UI. So having a QuickSimpleText item, which can > only do the simple case should be much faster to create. Not having a > QTextDocument and all that many members for all this many features. Of course > even with most of this feratures it was faster in 5.1, but still could be a > lot more , i think for the simple case. It still needs to do shaping and all that though, so some involvement with the text engine is required. However, I believe there is huge room for improvement there. There is https://bugreports.qt.io/browse/QTBUG-42853 <https://bugreports.qt.io/browse/QTBUG-42853> which covers some ideas around writing a faster implementation. > > I am very interested in solving issue as in our environment we are hit by the > degration and our product has to stay at 5.1 for now. > So keep on the good work! > > Best regards, > Gunnar Roth > > Gesendet: Donnerstag, 12. Februar 2015 um 11:56 Uhr > Von: "Robin Burchell" <robin...@viroteck.net <mailto:robin...@viroteck.net>> > An: "Rutledge Shawn" <shawn.rutle...@theqtcompany.com > <mailto:shawn.rutle...@theqtcompany.com>> > Cc: "development@qt-project.org <mailto:development@qt-project.org>" > <development@qt-project.org <mailto:development@qt-project.org>> > Betreff: Re: [Development] Item creation time in QML > On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn > <shawn.rutle...@theqtcompany.com <mailto:shawn.rutle...@theqtcompany.com>> > wrote: > >> Being able to do 500+items rectangles in one frame is decent, but not > >> awesome. Being able todo 130 text items in one frame, is less than ideal, > >> given that we often use several text items per cell in a list or table. > >> Text is probably the most important UI element we have. Being able to do > >> 10 buttons is, well, unfortunate :) If we look at Button, we see that it > >> is a fairly complex QML beast. Hierarchy is > >> > >> Button -> BasicButton -> Control -> FocusScope > >> > >> and there are quite a bit of stuff on every level, including the dynamic > >> style handling which will in turn create a StyleItem. > >> > >> And keep in mind that even though this isn’t the most high-end mac, it is > >> sitll a pretty decent computer, Qt is supposed to run on much worse > >> hardware than this. > >> > >> — > >> > >> There have been a few changes going into 5.5 which make these numbers > >> better than 5.4, but I still think we got quite a ways to go. > > > > That’s very interesting. > > > > Do you think it was ever better in past versions? > > I'm glad you asked: http://rburchell.com/QtQuickPerformance.pdf > <http://rburchell.com/QtQuickPerformance.pdf> > > > What do you think we should do about it? Mainly focus on trying to create > > fewer objects, or is there still a lot of headroom for making the creation > > more efficient? Is creation expensive because of constructor code, making > > too many signal/slot connections, or something else? > > I think there's plenty that can be done, because it *used* to be > better. We should aim for matching the performance we used to have at > the very least, ideally, for exceeding that. > > I'd say that one very particular case that needs attention is text > performance. It's pretty bad. > > As for why, specifically, it's slow, I did some profiling in the past, > but I don't have those results now. I plan to spend some time on that, > maybe on the weekend, and send some more information once that's done. > _______________________________________________ > Development mailing list > Development@qt-project.org <mailto:Development@qt-project.org> > http://lists.qt-project.org/mailman/listinfo/development > <http://lists.qt-project.org/mailman/listinfo/development>_______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
