[Interest] Material controls memory usage

[nus1998]

Hi All,


I made a simple comparison that it looks material controls cost  70 times 
memory as normal quick controls, is it expected?


my OS is win10 x64, with Qt 5.15.2 mingw64, here are the results:


|
button count
|
normal button memory usage(MB)
|
material button memory usage (MB)
|
|
100

|
24.2

|
130

|
|
300

|
27.7

|
343

|
|
500

|
30.9

|
555

|
|
avg. per 200 buttons:
|
3.35

|
212.5

|






___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML Singleton and QTimer?

[Jason H]

> Sent: Monday, May 10, 2021 at 3:08 AM
> From: "Ulf Hermann" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QML Singleton and QTimer?
>
> Hi,
>
> > GuiApplication::GuiApplication(int argc, char*argv[]):
> > QGuiApplication::QGuiApplication(argc, argv)
> > {
> > m_hardwareInterface = new HardwareInterface;
> > qmlRegisterSingletonInstance("com.company", 1, 0, "HardwareInterface", 
> > m_hardwareInterface);
> > }
>
> qmlRegisterSingletonInstance() is dangerous if you create your singleton
> in a different thread than the one the QML engine runs on. The QML
> engine expects to be able fiddle with internals of those objects via the
> metaobject system.
>
> It also does surprising things when you have multiple QML engines: The
> first one to access it grabs the objects and all others only see null.
>
> It also does not play ball with qmlRegisterTypesAndRevisions() the way I
> had intended. You cannot register an instance before the type because
> the type will then get rejected. You also cannot register an instance
> after the type because there is no way to hook into the type
> registration procedure without providing some kind of callback. If you
> could provide a callback, then that would be pretty much the same as
> providing a factory function, though.
>
> The whole qmlRegisterSingletonInstance() was a mistake, sorry about
> that. It's too easy to shoot yourself in the foot with it and there is
> no way to make its type visible at compile time. You should really use
> the QML_SINGLETON macro and let the QML engine handle the life cycle of
> the object. The QML engine will make sure to create and destroy it on
> the right thread. qmlRegisterSingletonInstance() will be deprecated
> before Qt 7.

It definitely seems that way! I hope this can be added to the documentation to
avoid other people going down this path? I was eager to finally use it, as it
would have simplified things on my side. But it looks like it is a difficult
thing to wield properly.


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Windows-64 specific QML UI flickering

[Rui Oliveira]

Hey!

I think I reported a similar thing in 
https://bugreports.qt.io/browse/QTBUG-93084


Is this like your problem?

It doesn't happen with Software or OpenGL rendering.

Às 13:12 de 10/05/2021, Benjamin TERRIER escreveu:



On Thu, 6 May 2021 at 02:21, Jason H > wrote:


I use mainly Mac and Android and I don't see these issues, however
the Windows 64 experience is very crunchy. I was asked to make a
simple serial port monitor. I developed on my mac. It's solid.
It's got QML UI using Rows, Columns, Text, TextEdits (Controls
v2), and a ComboBox (Controls v2) for selecting the serial port.

However, I've tried it on 2 HP laptops:
- The first shows triangular artifacts, like a GL triangle is
glitching, but the triangle is very acute, and fleeting.

- The other one doesn't glitch with the triangle, it redraws the
background then draws on top of it (as it should). But here's the
crazy thing, it's got a rhythm like a heart beat like
.|.|;.|.|; where the | indicate the text fields
disappearing, reappearing. (so in one cycle the controls flicker
twice with a short pause between them, and. along pose separating
them) One cycle is on the order of about 2 seconds.

Nothing in the UI falls into this pattern.  The serial port stuff
is async.

How do I fix this?



Does it look like this: https://bugreports.qt.io/browse/QTBUG-49866 

I was never able to fix it, but it only affected a Intel CPU that we 
only had in a couple of development PCs.


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 3D, Image Formats and SCXML license change in Qt 6?

[Kai Köhne]

Hi Benjamin,

Good catch! The license of the modules hasn’t changed in 6.1, so this is 
probably a copy/paste bug in the package metadata creation.

You can track https://bugreports.qt.io/browse/QTBUG-93630 to follow up.

Regards

Kai


From: Interest  On Behalf Of Benjamin TERRIER
Sent: Montag, 10. Mai 2021 14:02
To: Qt Interest 
Subject: [Interest] Qt 3D, Image Formats and SCXML license change in Qt 6?

Hi,

In the online installer when installing these 3 modules, the following text is 
shown in the description and tooltip:
This component is available under commercial licenses from The Qt Company, or 
under GPL v3. For open source use, please note the additional requirements 
compared to LGPL v3.

Implying that they are non longer licensed under LGPLv3.
However, according to the documentation they are still available under LGPLv3.

Same thing for the Qt 5 compatibility module, it shows the same text in the 
online installer.
But is licensed under GPLv2 and LGPLv3 according to the documentation.

I have not found a bug report about this.
Is the documentation correct, or is the online installer correct?

Regards,

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Windows-64 specific QML UI flickering

[Benjamin TERRIER]

On Thu, 6 May 2021 at 02:21, Jason H  wrote:

> I use mainly Mac and Android and I don't see these issues, however the
> Windows 64 experience is very crunchy. I was asked to make a simple serial
> port monitor. I developed on my mac. It's solid.
> It's got QML UI using Rows, Columns, Text, TextEdits (Controls v2), and a
> ComboBox (Controls v2) for selecting the serial port.
>
> However, I've tried it on 2 HP laptops:
> - The first shows triangular artifacts, like a GL triangle is glitching,
> but the triangle is very acute, and fleeting.
>
> - The other one doesn't glitch with the triangle, it redraws the
> background then draws on top of it (as it should). But here's the crazy
> thing, it's got a rhythm like a heart beat like .|.|;.|.|; where
> the | indicate the text fields disappearing, reappearing. (so in one cycle
> the controls flicker twice with a short pause between them, and. along pose
> separating them) One cycle is on the order of about 2 seconds.
>
> Nothing in the UI falls into this pattern.  The serial port stuff is async.
>
> How do I fix this?
>
>
>
> Does it look like this: https://bugreports.qt.io/browse/QTBUG-49866
I was never able to fix it, but it only affected a Intel CPU that we only
had in a couple of development PCs.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt 3D, Image Formats and SCXML license change in Qt 6?

[Benjamin TERRIER]

Hi,

In the online installer when installing these 3 modules, the following text
is shown in the description and tooltip:

This component is available under commercial licenses from The Qt Company,
> or under GPL v3. For open source use, please note the additional
> requirements compared to LGPL v3.


Implying that they are non longer licensed under LGPLv3.
However, according to the documentation they are still available under
LGPLv3.

Same thing for the Qt 5 compatibility module, it shows the same text in the
online installer.
But is licensed under GPLv2 and LGPLv3 according to the documentation.

I have not found a bug report about this.
Is the documentation correct, or is the online installer correct?

Regards,

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML Singleton and QTimer?

[Ulf Hermann]

Hi,


GuiApplication::GuiApplication(int argc, char*argv[]):
QGuiApplication::QGuiApplication(argc, argv)
{
m_hardwareInterface = new HardwareInterface;
qmlRegisterSingletonInstance("com.company", 1, 0, "HardwareInterface", 
m_hardwareInterface);
}


qmlRegisterSingletonInstance() is dangerous if you create your singleton 
in a different thread than the one the QML engine runs on. The QML 
engine expects to be able fiddle with internals of those objects via the 
metaobject system.


It also does surprising things when you have multiple QML engines: The 
first one to access it grabs the objects and all others only see null.


It also does not play ball with qmlRegisterTypesAndRevisions() the way I 
had intended. You cannot register an instance before the type because 
the type will then get rejected. You also cannot register an instance 
after the type because there is no way to hook into the type 
registration procedure without providing some kind of callback. If you 
could provide a callback, then that would be pretty much the same as 
providing a factory function, though.


The whole qmlRegisterSingletonInstance() was a mistake, sorry about 
that. It's too easy to shoot yourself in the foot with it and there is 
no way to make its type visible at compile time. You should really use 
the QML_SINGLETON macro and let the QML engine handle the life cycle of 
the object. The QML engine will make sure to create and destroy it on 
the right thread. qmlRegisterSingletonInstance() will be deprecated 
before Qt 7.


best,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest