Re: [Development] Nominating Dennis Oberst for approver rights

[Juha Vuolle]

+1

Juha

to 30. toukok. 2024 klo 9.47 Alexey Edelev via Development (
development@qt-project.org) kirjoitti:

>
> Hi all,
>
> I would like to nominate Dennis Oberst for approver rights in the Qt
> project.
>
> Dennis joined in 2022 and did a great job in various Qt subprojects,
> providing strong patches and insightful reviews. I personally appreciate
> his contributions to QtGrpc, which he continues to make.
>
> Changes owned:
> * https://codereview.qt-project.org/q/owner:dennis.obe...@qt.io
>
> Changes commented/voted on:
> * https://codereview.qt-project.org/q/commentby:dennis.obe...@qt.io
>
> Regards,
> Alexey.
>
> Alexey Edelev
>
> Software Engineer
>
> Qt Group
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
>
> *alexey.ede...@qt.io *
>
> *www.qt.io *
> [image:
> https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black-1.png]
> 
> [image:
> https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right.png]
>  [image:
> https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png]
>  [image:
> https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
>  [image:
> https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube-x2.png]
> 
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

Hi, sorry for just kind of resetting the thread, but we had a quick
discussion with Marc and Tor Arne.

There's an additional constraint that, at least on iOS/macOS, that the
OS/platform callback mechanisms depend on UI libraries (AppKit and
UIKit).
While making that work in QtCore could *maybe* technically be
possible, it'd just add to the effort and risk we'd be talking about
here.

Hence a concrete suggestion with a few specific questions.

Thing 1) In Qt 6.8 we'll add a QtGui dependency to QtNetworkAuth
module. With this the new Qt 6.8 features will work.
Thing 2) This QtGui dependency will be behind a Qt feature flag.
Thing 3) Later in Qt 6.9+, if the three QDS functionalities become
available via QtCore, then QtNetworkAuth drops the QtGui dependency.
IIUC dropping a private linkage shouldn't cause "transitive" problems.
The main questions:
Question 1) Do we foresee problems on introducing a Gui dependency to
QtNetworkAuth?
Question 2) Do we foresee problems in possibly later dropping the Gui
dependency?

ke 8. toukok. 2024 klo 12.51 Volker Hilsheimer via Development
(development@qt-project.org) kirjoitti:
>
>
>
> On 8 May 2024, at 07:32, Marc Mutz via Development 
>  wrote:
>
> On 07.05.24 18:46, Volker Hilsheimer wrote:
>
> In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a 
> browser” is not true for every possible call of the QDesktopServices API.
>
>
> We need something _now_ for QtNetworkAuth, though. What do these options mean 
> for OAuth support in QtNetworkAuth (my attempt at an analysis below).
>
>
>
> I question that. QtNetworkAuth’s 
> QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
> by users, as long as they are either willing to use Qt GUI, or to write their 
> own handler code (possibly inspired but what we have in Qt Gui).
>
>
> However, whether a new QCoreDesktopServices namespace becomes public QtCore 
> API or not in Qt 6.8 is somewhat irrelevant as long as it doesn’t do anything 
> on any platform. The QPA infrastructure in general, and the implementations 
> of QPlatformServices in particular is -as of now - not loaded by an 
> application that doesn’t use QtGui. And we haven’t even started discussing if 
> and how we’d like to make that happen. I do not anticipate that we will get 
> that infrastructure into Qt Core in time for the Qt 6.8 feature freeze in 
> three weeks; while it’s probably not rocket science to write the code, there 
> are evidently too many disagreements on (and probably several devils in) the 
> details.
>
>
> We have a template for this: the permission API. It's a) in QtCore and also 
> highly platform-dependent. I also, honestly, don't see the extraction of the 
> non-Gui code from the QPAs into some QtCore files or plugin as something 
> subject to feature freeze. It's kinda cleanup under the hood. Certainly we 
> can't argue that moving the implementation as private API is ok post-FF, but 
> moving the interface as public API now and moving the implementation as 
> private implementation detail post-FF is not, can we?
>
>
> The point of feature freeze is that we start stabilizing the release.
>
> Moving large chunks of code around, while not forbidden explicitly, doesn’t 
> move us to that end.
>
>
> I can see two options:
>
> 1) we leave it entirely to the application to implement a Core-only 
> equivalent of QDesktopServices
>
> Not fun, but not impossible either, esp given that whoever needs this can 
> take our existing code. We could even have that code in an example, at least 
> for some platforms. This doesn’t invalidate the improved OAuth support in 
> 6.8, esp if we assume that the vast majority of users today will use Qt Gui 
> anyway, and that Qt Core only use cases are rare enough to deal with the 
> alternative.
>
>
> AFAICT, this means one of the following:
>
> a) that we have to postpone QtNetworkAuth until new QtCore API is added,
> provided that any future intents/activities API actually pertains to and
> supports implementation of what OAuth needs. Danger of "the perfect is
> the enemy of the good" here.
>
>
>
> Depending on Qt Gui might not be perfect, but it’s good enough for the vast 
> majority of users.
>
>
> b) that QtNetworkAuth gets the undesired QtGui dependency, which becomes
> stale once new Core API is merged, but then has to be carried along for
> BC reasons.
>
>
> QtNetworkAuth doesn’t have to link against Qt Gui. The application does. Qt 
> NetworkAuth emits a signal, the application handles that.
>
> Or do I misinterpret what 
> https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28
>   (which is the example you referred to a few days ago) is doing and how that 
> relates to how things should be done in the future with new and improved Qt 
> NetworkAuth?
>
> Maybe it’s time to point at what new and improved Qt NetworkAuth we are 
> talking about… maybe it’s 
> https://codereview.qt-project.org/c/qt/qtnetworkauth/+/556023?
>

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

> QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
> at the user's discretion, and thus that currently won't force a Gui
> dependency.

(Ah shoot. Correcting myself, in the new qtnetworkauth class we do
need to call QDesktopServices::openUrl() too to forward any unhandled
URLs.)

> The concrete need for QtNetworkAuth at the moment is
> QDesktopServices::setUrlHandler() and
> QDesktopServices::unsetUrlHandler().
> There is a new (Qt 6.8) class which needs to use these *) and that
> would create a module-level Gui dependency (unless using plugins or
> somesuch).
>
> Hence I'm wondering if, as a pragmatic pre-move, moving the
> implementation of those two functions behind a private header in
> QtCore (IIUC this is Tor Arne's proposal) would be
> sensible/acceptable?
>
> *) In order to be able to use custom-scheme and https-scheme redirect_uris
>
> Cheers,
> Juha
>
> > On 6 May 2024, at 09:51, Lars Knoll via Development 
> >  wrote:
> >
> >
> >
> > On 6 May 2024, at 09:02, Marc Mutz via Development 
> >  wrote:
> >
> > Hi,
> >
> > Juha is currently improving the OAuth implementation in QtNetworkAuth.
> > The protocol involves launching the system browser to get an access
> > code, in turn used to get access tokens with which services can then be
> > accessed.
> >
> > OAuth therefore requires a UI to run the browser in, but not necessarily
> > a _G_UI (the system browser could be lynx). Even if a CLI tool like a
> > mail fetcher, backup program, or VPN client will eventually launch
> > Firefox or Chrome, I think it's too much to ask to link to QtGui just to
> > do the equivalent of exec xdf-open .
> >
> >
> > I’d agree with that. And there’s no way to do OAuth without launching a 
> > browser during the authentication process.
> >
> >
> > I've looked at the implementation of openUrl(), and the only
> > Gui-dependency is on the platform helpers. The handler registration is
> > only using Core functionality.
> >
> > I would therefore propose to move the services code from Gui to Core
> > (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
> > dependency.
> >
> > After a quick look, I can see two ways to do that:
> > - keep the platform handling code in the platform helpers, incl. Gui
> > dependency, and only move the handler registration to Core
> > - move the platform url handlers out of the platform helpers into (a
> > plugin for) Core
> >
> > The first would enable users to write their own handlers w/o Gui
> > dependency, but has the disadvantage that the code behaves differently,
> > depending on whether QtGui is loaded or not.
> >
> > The second would be more work, but with consistently better user experience.
> >
> > Is there a reason other than history for the openUrl handlers to be in
> > the platform handlers? We have XDG-code in QtCore already (mime types),
> > so we should have all the information in Core already to implement the
> > functionality, should we not?
> >
> >
> > I believe the reason for this is mainly history. Moving this to Qt Core 
> > makes sense IMO.
> >
> > I don’t think you need a separate plugin for Qt Core to implement this 
> > though. I’m a bit unsure about the windows code, but on Linux and macOS 
> > it’s simply launching ‘xdg-open’ or ‘open’. It would probably fit better to 
> > simply follow the usual pattern for Qt Core with a _platform.cpp 
> > implementation file.
> >
> > Cheers,
> > Lars
> >
> >
> >
> > Thanks,
> > Marc
> >
> > --
> > Marc Mutz  (he/his)
> > Principal Software Engineer
> >
> > The Qt Company
> > Erich-Thilo-Str. 10 12489
> > Berlin, Germany
> > www.qt.io
> >
> > Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> > Sitz der Gesellschaft: Berlin,
> > Registergericht: Amtsgericht Charlottenburg,
> > HRB 144331 B
> > --
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> >
> > --
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> >
> > --
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

ma 6. toukok. 2024 klo 11.05 Tor Arne Vestbø via Development
(development@qt-project.org) kirjoitti:
>
> There’s some overlap here with the more modern features of intents, 
> activities, etc, which we are hoping to add proper APIs for at some point, so 
> I suggest not doing any public API changes as part of this.
>
> We can move the registration APIs to QtCore as private APIs, that 
> QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move the 
> URL handling part of the QPA plugins to QtCore under src/corelib/platform

Imho (eventually) moving the public header to QtCore would make sense,
but as I understand it, there's some concerns and issues too.

QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
at the user's discretion, and thus that currently won't force a Gui
dependency.
The concrete need for QtNetworkAuth at the moment is
QDesktopServices::setUrlHandler() and
QDesktopServices::unsetUrlHandler().
There is a new (Qt 6.8) class which needs to use these *) and that
would create a module-level Gui dependency (unless using plugins or
somesuch).

Hence I'm wondering if, as a pragmatic pre-move, moving the
implementation of those two functions behind a private header in
QtCore (IIUC this is Tor Arne's proposal) would be
sensible/acceptable?

*) In order to be able to use custom-scheme and https-scheme redirect_uris

Cheers,
Juha

> On 6 May 2024, at 09:51, Lars Knoll via Development 
>  wrote:
>
>
>
> On 6 May 2024, at 09:02, Marc Mutz via Development 
>  wrote:
>
> Hi,
>
> Juha is currently improving the OAuth implementation in QtNetworkAuth.
> The protocol involves launching the system browser to get an access
> code, in turn used to get access tokens with which services can then be
> accessed.
>
> OAuth therefore requires a UI to run the browser in, but not necessarily
> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
> mail fetcher, backup program, or VPN client will eventually launch
> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
> do the equivalent of exec xdf-open .
>
>
> I’d agree with that. And there’s no way to do OAuth without launching a 
> browser during the authentication process.
>
>
> I've looked at the implementation of openUrl(), and the only
> Gui-dependency is on the platform helpers. The handler registration is
> only using Core functionality.
>
> I would therefore propose to move the services code from Gui to Core
> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
> dependency.
>
> After a quick look, I can see two ways to do that:
> - keep the platform handling code in the platform helpers, incl. Gui
> dependency, and only move the handler registration to Core
> - move the platform url handlers out of the platform helpers into (a
> plugin for) Core
>
> The first would enable users to write their own handlers w/o Gui
> dependency, but has the disadvantage that the code behaves differently,
> depending on whether QtGui is loaded or not.
>
> The second would be more work, but with consistently better user experience.
>
> Is there a reason other than history for the openUrl handlers to be in
> the platform handlers? We have XDG-code in QtCore already (mime types),
> so we should have all the information in Core already to implement the
> functionality, should we not?
>
>
> I believe the reason for this is mainly history. Moving this to Qt Core makes 
> sense IMO.
>
> I don’t think you need a separate plugin for Qt Core to implement this 
> though. I’m a bit unsure about the windows code, but on Linux and macOS it’s 
> simply launching ‘xdg-open’ or ‘open’. It would probably fit better to simply 
> follow the usual pattern for Qt Core with a _platform.cpp implementation file.
>
> Cheers,
> Lars
>
>
>
> Thanks,
> Marc
>
> --
> Marc Mutz  (he/his)
> Principal Software Engineer
>
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
>
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Feedback on Qt RESTful client development

[Juha Vuolle]

Hi,

I'm collecting thoughts on how to make developing Qt REST /client/
applications a smoother experience.

Here I'm thinking about a "typical" client application that wants to
talk with "typical" REST servers
as they exist today. As it stands today, the main options are
XMLHttpRequest on QML side and QtNetwork
classes on the C++ side (with per-application QML binding option).

REST  is a large and ~loosely defined umbrella and I'd appreciate your
thoughts - what would actually /help/?

In particular I'm interested in hearing about:
1) Current use cases and the bottlenecks/painpoints with them
2) Specifically about the seen utility of introducing a fetch() API,
see below  *)
3) Specifically about the seen utility for OpenAPI code-generation
(below), see below *)

If any thoughts, leave a comment here or here:
https://bugreports.qt.io/browse/QTBUG-112276

Thank you
Juha

*) Few of the more promising directions I've looked into are:

1) Adding fetch() support in QML. Fetch is a Promise based Javascript
API (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
   The reason I've picked it up is that it's a widely known JS API
which makes for quite compact and readable code.
   But - would you find this useful?

   To give an idea, fetching a JSON:
   fetch("urlhere")
 .then((response) => response.json())
 .then((json) => myModel.model = json)
 .catch((error) => console.log("Oh no", error)

2) Providing support for OpenAPI code generation tools;  with OpenAPI
you can generate Qt client networking boilerplate code based on an API
description (https://openapi-generator.tech/)
This would probably build on top of the existing cpp-qt-client
generator and add things like out-of-the-box QML support and build
system integration.
The concept is well-known and sound, but do you see use for this?

3) Improving Qt OAuth2 support https://bugreports.qt.io/browse/QTBUG-113218

4) Possibly: Convenience classes for dealing with tasks around offline
operation, caching, and also possibly convenience data models.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ivan Solovev as approver

[Juha Vuolle]

+1

Leave reviewing to Ivan you don't even have to run tests.

ti 15. kesäk. 2021 klo 14.19 Alex Blasche (alexander.blas...@qt.io) kirjoitti:
>
> Hi,
>
> I'd like to nominate Ivan Solovev as an approver for the Qt Project.
>
> Ivan has been working on various parts of the Qt6 port and has regularly 
> contributed to QtBase  modules, QtPositioning, QtNfc & other modules. 
> Personally, I am particularly thankful for his help in furthering the Qt 
> Bindings support in QtPositioning and his review of countless other patches 
> in the same domain.
>
> He has authored the following patches:
> https://codereview.qt-project.org/q/owner:ivan.solovev%2540qt.io,100
> and reviewed the following:
> https://codereview.qt-project.org/q/reviewer:ivan.solovev%2540qt.io,100
>
> Since  both our office rooms share one wall I am also thankful for many 
> technical discussions who broke the enforced solitude of the corona days :)
>
> --
> Alex
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QML instantiation performance

[Juha Vuolle]

Hi Gunnar,

> But what about the "QQml_removeValueTypeProvider: was asked to remove
> provider 0x2b4c2ac but it was not found"
> messages? Don't you get that with 5.4? Did you change something in your patch 
> for 5.4?

I get this on the 5.3.1 (not on 5.1.1) on my linux, right at the end of test:

PASS   : tst_librarymetrics_performance::cleanupTestCase()
Totals: 201 passed, 0 failed, 0 skipped
* Finished testing of tst_librarymetrics_performance *
QQml_removeValueTypeProvider: was asked to remove provider
0x7fb94a951850 but it was not found

But I have no crashes etc.

Juha
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML instantiation performance

[Juha Vuolle]

Hi all,

I filed a bug to follow-up this topic:
https://bugreports.qt-project.org/browse/QTBUG-43096

Chris your hint on the Qt module initialisation was correct, I was
able to now run on both 5.1.1 and 5.3.1. The results are in line with
what's been discussed so far (the cached performance is not as bad).

Due to the severe and holistic impact of this issue for QML and its
usability in embedded use cases after 5.2+ and the likelihood of V4's
role in this, I would warmly welcome if you Lars or Simon could
comment on the topic.

thank you,
Juha
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML instantiation performance

[Juha Vuolle]

> Juha, does that resolve the issues for you?  Gunnar Roth, does that fix the

Yes it does, tests pass on 5.3.1. Big thanks Chris and Matt!

Going back to the original issue I'd need reference from 5.1.1 where
tests won't run, I get same issue as Gunnar:

> file:///data/item.1.qml:3:1: Item is not a type

I believe it is this issue:
https://bugreports.qt-project.org/browse/QTBUG-32078
But I could not find the fix (my guess is that it was going to 5.1.2
but then went to 5.2.0)

Chris I noticed you've reviewed the auto test changes related to that
bug, would happen to know about the fix (I could backport to 5.1.1)?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML instantiation performance

[Juha Vuolle]

Hello,

> It appears that the QQuickValueTypeProvider instances are continuously
> recreated (spinning at 100% and locking the incubator thread, which the main
> thread is waiting on).  Lars or Simon, are you able to guess what might
> cause this issue?  The implementation of qmlClearTypeRegistrations seems
> fairly straightforward, but my memory of the complexities of value type
> providers is hazy.
>
> Juha, are you seeing this issue also, or do I just have a broken build
> somehow?

Yes happens here too with similar back traces and high CPU loads (5.3.1 fedora).

This reminds me of an open bug that I hit when trying to use incubators:
https://bugreports.qt-project.org/browse/QTBUG-36826
(I am not sure if Monsieur Alpert is actively looking at issues these days.)
In my application I've set some asynchronous loadings to false because
they hang occasionally.

cheers,
Juha
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML instantiation performance

[Juha Vuolle]

Hey Chris,

Thanks heaps. I'll have a look and get back with any findings (may
take a day or two before I get to it).

cheers,
Juha

2014-11-27 3:51 GMT+02:00 Chris Adams :
> Hi Juha,
>
> For some more light on this issue, are you able to run the
> qtdeclarative/tests/benchmarks/qml/librarymetrics_performance benchmark on
> both 5.1 and 5.3 (you may have to backport to 5.1 as IIRC I made some
> changes to the way the components were instantiated for 5.2 before the
> benchmark was integrated, but I may be wrong about that.  It was originally
> written prior to Qt5.0 release so with some minor changes it will definitely
> work against 5.1).
>
> The benchmarks are quite granular, and should allow you to see precisely
> which part of the component instantiation is significantly slower.
>
> Kind regards,
> Chris Adams.
>
>
> www.qinetic.com.au - Qt And QML User Experience Specialists
>
> On Wed, Nov 26, 2014 at 6:08 PM, Juha Vuolle  wrote:
>>
>> Hello,
>>
>> apologies for cross-posting. I find this such a fundamental issue that I
>> feel
>> at least having the best possible understanding of it worth it (if any
>> exists, which is also
>> a valuable information in itself). I am happy to help if there is
>> anything I could check.
>>
>> thanks,
>> Juha
>>
>> ---
>>
>> Hello,
>>
>> I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a
>> slowdown in QML (15..35% slower).
>> This primarily relates to component instantiation and seems quite
>> consistent across the platforms and
>> QPAs I’ve used recently.
>>
>> If you have any insights, thoughts or something I could check I would
>> highly appreciate them.
>>
>> I’ve tested on dual & quadcore imx6 (both EGLFS and XCB) embedded
>> platform as well as
>> few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest
>> 5.4.0. The slowdown varies
>> but is fairly consistently between 15..35 %. Instantiation CPU loads
>> do not seem to be particularly high (< 70%).
>>
>> Running QML profiler seems to make results less predictable. So I made
>> a very simple application startup timer
>> that checks main() -> QQuickWindow::beforeSynchronizing() ->
>> beforeRendering() -> afterRendering() -> frameSwapped().
>> Please find my "highly scientific" measurements below. I slowed down
>> the CPU to make things more clear on the desktop I’m writing
>> this email from. This behaviour is not specific to only application
>> startup but later runtime instantiations seem also slower.
>>
>> I am grateful for any thoughts or things I could check.
>>
>> Thanks,
>> Juha
>>
>> Qt 5.1.1 low CPU qtquickcontrols gallery example startup:
>> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
>> 950
>> 2. onBeforeRendering() time it took from beforeSynchronizing: 3
>> 3. onAfterRendering() time it took from beforeRendering: 1572
>> 4. onFrameSwapped() time it took from afterRendering: 5
>> = 2530 ms for first frame swapped.
>>
>> Qt 5.3.1 low CPU qtquickcontrols gallery example startup:
>> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
>> 1843
>> 2. onBeforeRendering() time it took from beforeSynchronizing: 364
>> 3. onAfterRendering() time it took from beforeRendering: 1039
>> 4. onFrameSwapped() time it took from afterRendering: 83
>> = 3329 ms for first frame swapped.
>>
>> Qt 5.1.1 low CPU my application startup:
>> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
>> 809
>> 2. onBeforeRendering() time it took from beforeSynchronizing: 3
>> 3. onAfterRendering() time it took from beforeRendering: 1373
>> 4. onFrameSwapped() time it took from afterRendering: 88
>> = 2273 ms for the first frame swapped
>>
>> Qt 5.3.1 low CPU my application startup:
>> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
>> 1341
>> 2. onBeforeRendering() time it took from beforeSynchronizing: 4
>> 3. onAfterRendering() time it took from beforeRendering: 2184
>> 4. onFrameSwapped() time it took from afterRendering: 10
>> = 3539 ms for the first frame swapped
>> ___
>> 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

[Development] QML instantiation performance

[Juha Vuolle]

Hello,

apologies for cross-posting. I find this such a fundamental issue that I feel
at least having the best possible understanding of it worth it (if any
exists, which is also
a valuable information in itself). I am happy to help if there is
anything I could check.

thanks,
Juha

---

Hello,

I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a
slowdown in QML (15..35% slower).
This primarily relates to component instantiation and seems quite
consistent across the platforms and
QPAs I’ve used recently.

If you have any insights, thoughts or something I could check I would
highly appreciate them.

I’ve tested on dual & quadcore imx6 (both EGLFS and XCB) embedded
platform as well as
few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest
5.4.0. The slowdown varies
but is fairly consistently between 15..35 %. Instantiation CPU loads
do not seem to be particularly high (< 70%).

Running QML profiler seems to make results less predictable. So I made
a very simple application startup timer
that checks main() -> QQuickWindow::beforeSynchronizing() ->
beforeRendering() -> afterRendering() -> frameSwapped().
Please find my "highly scientific" measurements below. I slowed down
the CPU to make things more clear on the desktop I’m writing
this email from. This behaviour is not specific to only application
startup but later runtime instantiations seem also slower.

I am grateful for any thoughts or things I could check.

Thanks,
Juha

Qt 5.1.1 low CPU qtquickcontrols gallery example startup:
1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 950
2. onBeforeRendering() time it took from beforeSynchronizing: 3
3. onAfterRendering() time it took from beforeRendering: 1572
4. onFrameSwapped() time it took from afterRendering: 5
= 2530 ms for first frame swapped.

Qt 5.3.1 low CPU qtquickcontrols gallery example startup:
1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1843
2. onBeforeRendering() time it took from beforeSynchronizing: 364
3. onAfterRendering() time it took from beforeRendering: 1039
4. onFrameSwapped() time it took from afterRendering: 83
= 3329 ms for first frame swapped.

Qt 5.1.1 low CPU my application startup:
1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 809
2. onBeforeRendering() time it took from beforeSynchronizing: 3
3. onAfterRendering() time it took from beforeRendering: 1373
4. onFrameSwapped() time it took from afterRendering: 88
= 2273 ms for the first frame swapped

Qt 5.3.1 low CPU my application startup:
1. onBeforeSynchronizing() for the FIRST time, time it took from main(): 1341
2. onBeforeRendering() time it took from beforeSynchronizing: 4
3. onAfterRendering() time it took from beforeRendering: 2184
4. onFrameSwapped() time it took from afterRendering: 10
= 3539 ms for the first frame swapped
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development