Re: [Interest] Skybox Qt Quick3D bad performance in Android

[joao morgado via Interest]

 Hi 

Thank you for your anwser and sorry by my late replay.
Using ktx files instead of hdr is alot better indeed, in my tablet, dropped the 
load time from 55seconds to aprox. 1 or 2 seconds wich what is expected.I guess 
the only downside is the file size, the 2.1MB hdr file grown up to 59MB ktx, 
but I'm ok with that.  
In my android mobile, compilation still fails, however I never used 
idealSurfaceFormat(), I always get an error of:
 undefined reference to `QQuick3D::idealSurfaceFormat(int)'
The following example is version 2 with the idealSurfaceFormat() where that 
error happens, when compiling for linux and for android.

SkyBoxTest2.zip

| 
| 
|  | 
SkyBoxTest2.zip


 |

 |

 |




#include #include 
#include #include #include 
int main(int argc, char *argv[]){   // 
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication app(argc, argv);
QSurfaceFormat::setDefaultFormat(QQuick3D::idealSurfaceFormat(4));
QQmlApplicationEngine engine;const QUrl 
url(QStringLiteral("qrc:/main.qml"));QObject::connect(, 
::objectCreated, , [url](QObject 
*obj, const QUrl ) {if (!obj && url == objUrl)
QCoreApplication::exit(-1);}, Qt::QueuedConnection);engine.load(url);
return app.exec();}

Is this a Qt bug, or a bug of mine   ?  What am I missing  ?
ThanksJoão
Em segunda-feira, 2 de agosto de 2021 10:03:00 GMT+1, Laszlo Agocs 
 escreveu:  
 
 #yiv7629575724 P {margin-top:0;margin-bottom:0;}Hi,
https://doc.qt.io/qt-6/qtquick3d-requirements.html#opengl-specifics (calling 
and honoring QQuick3D::idealSurfaceFormat())  is probably required in this 
case. (otherwise, not sure why it ends up using GLSL ES 100 shaders)

Yet better, in Qt 6.1 and newer the whole pre-filtering process can be, and 
should be, done 
offline:https://doc.qt.io/qt-6/quick3d-asset-conditioning-ibl.html#pre-generating-ibl-cubemap

This boils down to, with your example, running 'balsam galaxy.hdr' and 
referencing the generated galaxy.ktx from qml.
If you were using CMake this could also be automated and left to the build 
system by adding something like the following to your CMakeLists:
qt6_quick3d_bake_lightprobe_hdri(target "ibl_assets"    PREFIX        "/"    
FILES        "galaxy.hdr")
and then referencing "galaxy.ktx" from the qml file.

Best regards,Laszlo

From: Interest  on behalf of joao morgado via 
Interest 
Sent: Saturday, July 31, 2021 3:52 AM
To: Qt Interest 
Subject: [Interest] Skybox Qt Quick3D bad performance in Android I'm testing 
Quick3D on Android, all good, but if I use a skybox the performance is really 
bad or does not work at all.

The following test project with  trivial code is just a skybox and a red 
cilinder. 
SkyBoxTest.zip


| 
| 
|  | 
SkyBoxTest.zip


 |

 |

 |



Runs fine in desktop linux mint, windows, MacOS, iPhone, but in my 2 android 
devices:

- tablet Lenovo Tab M10 TB-X306F, OS Android 11, when I run the program, I get 
a black screen, it takes 55 seconds to load the image of the skybox and the red 
cylinder
- mobile nokia 5.4 OS Android 10:  compilation fails with the following errors: 
---E
 VpsExtension: Failed to get binder for service "vendor.vpsservice"E 
VpsExtension: Failed to get binder for service "vendor.vpsservice"I 
AdrenoGLES-0: ERROR: 0:2: '' :     GLSL error: extension 
'GL_EXT_shader_texture_lod' is not supportedI AdrenoGLES-0: ERROR: 0:77: 
'textureCubeLodEXT' : no matching overloaded function foundI AdrenoGLES-0: 
ERROR: 0:77: 'xyz' :  field selection requires structure, vector, or matrix on 
left hand sideI AdrenoGLES-0: ERROR: 0:77: 'return' : function return is not 
matching type:I AdrenoGLES-0: ERROR: 4 compilation errors.  No code 
generated.07-31 02:35:03.170 24150 24253 I AdrenoGLES-0:W 
libSkyBoxTest_arm64-v8a.so: Failed to compile shader: ERROR: 0:2: '' :     GLSL 
error: extension 'GL_EXT_shader_texture_lod' is not supportedW 
libSkyBoxTest_arm64-v8a.so: ERROR: 0:77: 'textureCubeLodEXT' : no matching 
overloaded function foundW libSkyBoxTest_arm64-v8a.so: ERROR: 0:77: 'xyz' :  
field selection requires structure, vector, or matrix on left hand sideW 
libSkyBoxTest_arm64-v8a.so: ERROR: 0:77: 'return' : function return is not 
matching type:W libSkyBoxTest_arm64-v8a.so: ERROR: 4 compilation errors.  No 
code generated.07-31 02:35:03.170 24150 24253 W 
libSkyBoxTest_arm64-v8a.so:07-31 02:35:03.170 24150 24253 W 
libSkyBoxTest_arm64-v8a.so:W libSkyBoxTest_arm64-v8a.so: Source was:W 
libSkyBoxTest_arm64-v8a.so: #version 100W libSkyBoxTest_arm64-v8a.so: 
#extension GL_EXT_shader_texture_lod : requireW libSkyBoxTest_arm64-v8a.so: 
precision highp float;W libSkyBoxTest_arm64-v8a.so: precision highp int;07-31 
02:35:03.170 24150 24253 W libSkyBoxTest_arm64-v8a.so:W 
libSkyBoxTest_arm64-v8a.so: struct LightSourceW libSkyBoxTest_arm64-v8a.so: {W 
libSkyBoxTest_arm64-v8a.so:     vec4 

Re: [Interest] Compile Qt 6.2.1 from source

[joao morgado via Interest]

 
> My rule of thumb: 2 GB of RAM per logical processor to do a compilation. So 
> 16 
> GB of RAM is sufficient for a 4-core system (8 CPUs), but not for 6-core (12 
> > CPUs).
> But this doesn't apply to qtwebengine. That thing has a few VERY big files > 
> that are concatenation of a lot of small ones and take multiple GB of RAM to 
> > compile. If you don't need qtwebengine, don't download it and don't build 
> it.> sdfs
Thanks for this info. 

I have another question, I sucessfully build the dev branch, then I tried to 
build the branch 6.2.0 in another directory, using the same build parameters, 
but it failled with the following messages.
Any ideias why this error happened ?Thanks
[ 20%] Running AUTOMOC file extraction for target Scxml
Consolidate compiler generated dependencies of target repc
[ 20%] Running AUTOMOC file extraction for target Sensors
[ 20%] Built target SerialPort_automoc_json_extraction
Updating 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/linguist_en.qm'...
Updating 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/qtwebsockets_en.qm'...
lrelease error: cannot create 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/linguist_en.qm': No 
such file or directory
lrelease error: cannot create 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/qtwebsockets_en.qm':
 No such file or directory
make[2]: *** 
[qttranslations/translations/CMakeFiles/updateqm-linguist_en.ts.dir/build.make:70:
 qttranslations/translations/CMakeFiles/updateqm-linguist_en.ts] Erro 1
make[2]: *** 
[qttranslations/translations/CMakeFiles/updateqm-qtwebsockets_en.ts.dir/build.make:70:
 qttranslations/translations/CMakeFiles/updateqm-qtwebsockets_en.ts] Erro 1
make[1]: *** [CMakeFiles/Makefile2:259792: 
qttranslations/translations/CMakeFiles/updateqm-linguist_en.ts.dir/all] Erro 2
make[1]: *** A aguardar por trabalhos não terminados
make[1]: *** [CMakeFiles/Makefile2:244804: 
qttranslations/translations/CMakeFiles/updateqm-qtwebsockets_en.ts.dir/all] 
Erro 2
[ 20%] Built target repc
Updating 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/qtwebengine_en.qm'...
lrelease error: cannot create 
'/home/joao/qt6.2.0/qt5/qt6.2.0-build/qtbase/./translations/qtwebengine_en.qm': 
No such file or directory
make[2]: *** 
[qttranslations/translations/CMakeFiles/updateqm-qtwebengine_en.ts.dir/build.make:70:
 qttranslations/translations/CMakeFiles/updateqm-qtwebengine_en.ts] Erro 1
make[1]: *** [CMakeFiles/Makefile2:244830: 
qttranslations/translations/CMakeFiles/updateqm-qtwebengine_en.ts.dir/all] Erro 
2
[ 20%] Built target Scxml_automoc_json_extraction
[ 20%] Built target Positioning_automoc_json_extraction
[ 20%] Built target Sensors_automoc_json_extraction
[ 20%] Built target DesignerComponentsPrivate_automoc_json_extraction
make: *** [Makefile:146: all] Erro 2
joao@joao-Lenovo-Legion-Y530-15ICH:~/qt6.2.0/qt5/qt6.2.0-build$ git branch
* 6.2.0
  dev
joao@joao-Lenovo-Legion-Y530-15ICH:~/qt6.2.0/qt5/qt6.2.0-build$ 



Em sábado, 2 de outubro de 2021 02:11:38 GMT+1, Thiago Macieira 
 escreveu:  
 
 On Friday, 1 October 2021 08:52:09 PDT joao morgado via Interest wrote:
> cmake --build . -j 6
> and it works very well, much less memory used and the pc was usable during
> compile time

My rule of thumb: 2 GB of RAM per logical processor to do a compilation. So 16 
GB of RAM is sufficient for a 4-core system (8 CPUs), but not for 6-core (12 
CPUs).

But this doesn't apply to qtwebengine. That thing has a few VERY big files 
that are concatenation of a lot of small ones and take multiple GB of RAM to 
compile. If you don't need qtwebengine, don't download it and don't build it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
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 5.15 LTS vs Qt 6.2 LTS

[Ulf Hermann]

There are no patient killing bugs in the underlying OS or the previously 
used drivers. Those only exist in the new drivers, new OS patches and 
new Qt code. All of the new code has to be written following 62304 SDLC


Although I doubt that Windows XP or the new graphics drivers are free of 
patient killing bugs, I have to admit that you have a point here: If MS, 
AMD, NVidia etc. went through the certification process with their 
software, we can trust their software as much as we can trust anything 
in such a system.


Now, what you probably want from Qt is a package that eliminates most of 
those 5000+ bugs and that can itself be certified or at least accepted 
in the approval process. The way to get there might be as follows:


1. Define a the feature set you need from Qt.
2. Turn off all unnecessary features using -no-feature-xyz on the 
configure script (possibly defining more features in order to be able to 
turn them off).
3. Wade through the bug database and sort out the bugs that remain valid 
for such a stripped down Qt.

4. Deal with those bugs in whatever way the approval process mandates.
5. Port the resulting Qt to your target platform.

I might be wrong with those steps because I don't know the approval 
process. Yet, I'm sure there is some pragmatic way to produce what you 
want. You may want to share your ideas on what it actually takes.


While all of this is possible, it obviously is a lot of work. If you 
want to do the work yourself, let's discuss the details here. If you 
want to pay for such work to be done, you may want to get in contact 
with the Qt Company. If you want to lament about such a specialized Qt 
not materializing out of thin air, you got my sympathies, but you may 
not get everybody's sympathies here. If you want to repeat that no one 
you know is using Qt anymore, that won't be necessary. We've read it 
often enough.


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

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Roland Hughes via Interest]

On 10/1/2021 10:52 AM, Ulf Hermann wrote:

I doubt you get a paid-for 5.15 LTS under an Open Source licence,
so no, this is not comparable a̲t̲ ̲a̲l̲l̲.

I did not compare to anything. Roland listed a number of open source
projects with LTS versions_after_  I wrote this.

If you want to discuss the issue of "I want a supported open source LTS
of Qt for recent systems", then I suggest you continue one of the
existing threads on this topic. This one here is about outdated systems.


Correction.

This one is about **Production** systems. No system is ever outdated 
while it is in production and performing its designated task.


It's about the production systems regulated refrigerator and freezer 
temperatures in meat packing plants so you don't die from Botulism or 
some other illness one gets when meat/poultry are stored at improper 
temperatures.


It's about the systems that ensure when you are out on the town you can 
quickly stop at an ATM to get cash.


It's about the systems that regulate the temperatures in brewing vats so 
what comes out of that can/bottle is actually beer.


It's about those *Production* systems our friend Scott (at least I hope 
his name is Scott, I don't remember for certain) has to maintain for 
Intel so you can have computers to run Qt on.


None of these systems are "outdated." They become outdated when they can 
no longer perform their assigned tasks.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS

[Roland Hughes via Interest]

On 10/1/2021 5:00 AM, Ulf Hermann wrote:

1) On rare occasions patient killing bugs like this one get fixed.

https://bugreports.qt.io/browse/QTBUG-12055  



This has very little to do with "security" unless one puts application
stability under the security heading.

That's exactly the safety (not security) argument I was expecting. The
patient killing bugs in the underlying OS and drivers etc will not be
fixed anymore, though. So even if we had decided to support XP with Qt6,
you still wouldn't have gained much.


There are no patient killing bugs in the underlying OS or the previously 
used drivers. Those only exist in the new drivers, new OS patches and 
new Qt code. All of the new code has to be written following 62304 SDLC


https://www.iso.org/standard/38421.html

The existing stripped down OS and physical processor has already been 
through multiple 510K submissions not to mention IEC 60601-1 and IEC 
62353 and a few other IEC testing an approval processes.


https://incompliancemag.com/article/medical-device-testing-requirements-for-510k-submissions/

https://www.intertek.com/medical/regulatory-requirements/iec-60601-1/

https://www.mddionline.com/testing/safety-testing-medical-devices-iec-62353-explained

The only patient killing bugs left are the ones in the library(ies) from 
third parties and those we introduce ourselves. The 62304 SDLC and 
rigorous QA process ensures that we will catch the ones /we/ introduce.


When a tool/library bug database has north of 5,000 open bugs though, it 
becomes physically impossible to test a medical device for all of them, 
especially those like 12055 which result from or part of the 
single-thread-i-ness of Qt.



2) Updated hardware support.

I wouldn't trust a hacked together system with 3rdparty drivers and
outdated software monkey-patched to work with my shiny 4k monitor to be
free of patient killing bugs. Or, I would only trust it if all that
stuff is carefully tested to be compatible with each other. Such testing
and bug fixing is expensive. Here we're back at square 1.


Square 1, no. Note even close.

Exactly what do you think MS Windows and Linux and BSD are? Microsoft 
doesn't write those drivers. They have a tiny set of generic drivers 
many things can function with at a minimum level, just like the generic 
video drivers in Linux which are also 3rdparty drivers.


Nvidia writes the video drivers and releases them to Microsoft, various 
Linux distros, etc.


HP/Compaq, Lenovo/Chicony, Logitech, etc. all write custom drivers for 
their own hardware and make them public as well. Microsoft didn't write 
the keyboard driver to make all of those special music/email/Internet 
buttons work at the top of this keyboard


https://www.logikalsolutions.com/wordpress/wp-content/uploads/2020/11/gigaware-2600460-keyboard.jpeg

The company that makes the Gigaware brand did. Microsoft didn't write 
the keyboard driver to make all of these keyboard buttons work.


https://www.logikalsolutions.com/wordpress/wp-content/uploads/2020/01/Logitech_Y-SV39_keyboard.jpg

Logitech (or someone they paid) did.

Compaq (or someone they paid) did it for this keyboard back when Compaq 
existed.


https://www.logikalsolutions.com/wordpress/wp-content/uploads/2018/05/cropped-IMG_2018-05-27_16-08-26-1.jpeg

When you plug in a "standard" 104-key keyboard and Windows loads the 
generic Windows driver for it, the keyboard itself has not been tested 
with that driver. Not really. When you bought that keyboard for $6 brand 
new at a physical store you can be certain testing was an almost 
non-existent part of its manufacture. The same goes for sub $15 video cards.


As for the video drivers Nvidia, AMD, etc. quietly release for Windows 
XP they work as well, in many cases better than, the drivers they 
publicly release for Windows 10 and other "current" platforms. The 
developers tend to put more effort into drivers that don't have an 
auto-push method of distribution.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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