Re: [Interest] Transparent rectangle with radius in one side
Sorry for the formatting. Rich formatting ruined it. Here we go again :
Hello,
We have a Quick scene where we draw a lot of semi-transparent rectangles and
those rectangles are rounded in one side. As a representative :
Rectangle {
id: clipper
width: 100
height: 100
opacity: 0.5
clip: true
Rectangle {
id: clipped
radius: 20.0
width: parent.width + radius
height: parent.height
color: 'red'
}
}
As it can be seen from the snippet above we use clipping to achieve rounding in
one side however that comes with a significant cost in batching as
the number of those rectangles are quite high. I've looked at what we can do to
get rid of clipping while preserving the existing and UI what I've found is as
follows:
Using Canvas API in QML
This will probably be slower than QQuickRectangle with clipping.
Using QQuickPaintedItem with QPainter API
This will be faster than canvas API but still slower than QQuickRectangle with
clipping.
Custom QQuickItem
This seems like the only way we can outperform QQuickRectangle with clipping
however the amount of implementation needed for a simple rounded rectangle
makes me think twice
about this approach. TBH I'm also a bit scared about some potential issues like
aliasing.
Using OpacityMask from QtGraphicalEffects
I am not sure about this approach. Can you shed some light on how this works
behind the scenes in scene graph renderer if I have, let's say, a hundred
instances of the following :
Rectangle {
// some properties
OpacityMask {
// some properties
}
}
As far as I understand each shader is a unique state in graphics API which
results in a seperate draw call but is it also the case if we use the same
shader for repeated items like above ?
I mean this should be fine if the shader is set for once because I assume items
can be batched afterwards. But if each item requires a different batch then
this has no gain over clipping.
Am I correct about the assumptions I make above regarding the performance
characteristics ? What is the best way to deal with this ?
Thank you.
Murat Seker
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Transparent rectangle with radius in one side
Hello,
We have a Quick scene where we draw a lot of semi-transparent rectangles and
those rectangles are rounded in one side. As a representative :
Rectangle { id: clipper width: 100 height: 100 opacity: 0.5
clip: true
Rectangle { id: clipped radius: 20.0 width:
parent.width + radius height: parent.height color: 'red' }}
As it can be seen from the snippet above we use clipping to achieve rounding in
one side however that comes with a significant cost in batching as the number
of those rectangles are quite high. I've looked at what we can do to get rid of
clipping while preserving the existing and UI what I've found is as follows:
Using Canvas API in QMLThis will probably be slower than QQuickRectangle with
clipping.
Using QQuickPaintedItem with QPainter APIThis will be faster than canvas API
but still slower than QQuickRectangle with clipping.
Custom QQuickItemThis seems like the only way we can outperform QQuickRectangle
with clipping however the amount of implementation needed for a simple rounded
rectangle makes me think twice about this approach. TBH I'm also a bit scared
about some potential issues like aliasing.
Using OpacityMask from QtGraphicalEffectsI am not sure about this approach. Can
you shed some light on how this works behind the scenes in scene graph renderer
if I have, let's say, a hundred instances of the following :
Rectangle { // some properties
OpacityMask { // some properties }}
As far as I understand each shader is a unique state in graphics API which
results in a separate draw call but is it also the case if we use the same
shader for repeated items like above ?
I mean this should be fine if the shader is set for once because I assume items
can be batched afterwards. But if each item requires a different batch then
this has no gain over clipping.
Am I correct about the assumptions I make above regarding the performance
characteristics ? What is the best way to deal with this ?
Thank you.
Murat Seker
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Compile Qt 6.2.1 from source
On Monday, 4 October 2021 14:43:08 PDT joao morgado via Interest wrote: > Hi Thiago > "git describe" shows > > v6.2.0-3-g1d8225dd > and "git branch" shows > 6.2.0 The first one is fine. That indicates 3 commits past the v6.2.0 tag. The second one is weird. The 6.2.0 branch shouldn't have moved after the tag, but it's not a problem. > I did a fresh install from start: git clone ..., git checkout 6.2.0, git > submodule update, perl init-repository, again a git sub module update, > configure ... , cmake --build I got the same type of error: Please insert "-j1 -v" to the cmake --build line (after --build) and paste the output. PS: you should install ninja. -- 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
Re: [Interest] Compile Qt 6.2.1 from source
Hi Thiago "git describe" shows v6.2.0-3-g1d8225dd and "git branch" shows 6.2.0 I did a fresh install from start: git clone ..., git checkout 6.2.0, git submodule update, perl init-repository, again a git sub module update, configure ... , cmake --build I got the same type of error: [ 11%] Built target Scxml_autogen [ 11%] Building CXX object qttools/src/linguist/lprodump/CMakeFiles/lprodump.dir/.rcc/qrc_proparser.cpp.o Updating '/home/joao/qt6teste/qt5/qt6-build/qtbase/./translations/linguist_en.qm'... lrelease error: cannot create '/home/joao/qt6teste/qt5/qt6-build/qtbase/./translations/linguist_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[1]: *** [CMakeFiles/Makefile2:261912: qttranslations/translations/CMakeFiles/updateqm-linguist_en.ts.dir/all] Erro 2 make[1]: *** A aguardar por trabalhos não terminados [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/__/__/src/scxml/qscxmlexecutablecontent.cpp.o [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/__/__/src/scxml/qscxmltabledata.cpp.o [ 11%] Built target qtattributionsscanner [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/generator.cpp.o [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/main.cpp.o [ 11%] Linking CXX executable ../../../../qtbase/bin/lconvert [ 11%] Built target lconvert [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/qscxmlc.cpp.o [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/scxmlcppdumper.cpp.o [ 11%] Built target DesignerComponentsPrivate_autogen [ 11%] Building CXX object qtscxml/tools/qscxmlc/CMakeFiles/qscxmlc.dir/.rcc/qrc_templates.cpp.o [ 11%] Built target Sensors_autogen [ 11%] Linking CXX executable ../../../../qtbase/libexec/lprodump [ 11%] Built target lprodump [ 11%] Linking CXX executable ../../../qtbase/bin/qscxmlc [ 11%] Built target qscxmlc make: *** [Makefile:146: all] Erro 2 Thanks for your help Thiago, but I'm gonna give up on this, life is short and I also figure out the problem of SoundEffect not working on dev branch, gstreamer had not been configured. I had to install a bunch of dependencies of gstreamer and wayland libs, then a new build of the dev branch made the sound work perflectly. Thanks again João Em segunda-feira, 4 de outubro de 2021 19:54:15 GMT+1, Thiago Macieira escreveu: On Sunday, 3 October 2021 12:36:52 PDT joao morgado via Interest wrote: > The second installation that failled I git cloned to /home/joao/qt6.2.0/qt5, > configured from /home/joao/qt6.2.0/qt5/qt6.2.0-build . I did a checkout to > branch 6.2.0 before the "perl init-repository" Hello João Please confirm that the correct checkout was achieved. On the top-level, please run git describe and it should print: v6.2.0 Then please run "git submodule update" to ensure all the submodules are at their correct commits. -- 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] Compile Qt 6.2.1 from source
On Sunday, 3 October 2021 12:36:52 PDT joao morgado via Interest wrote: > The second installation that failled I git cloned to /home/joao/qt6.2.0/qt5, > configured from /home/joao/qt6.2.0/qt5/qt6.2.0-build . I did a checkout to > branch 6.2.0 before the "perl init-repository" Hello João Please confirm that the correct checkout was achieved. On the top-level, please run git describe and it should print: v6.2.0 Then please run "git submodule update" to ensure all the submodules are at their correct commits. -- 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
Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS
Hi Roland et al, Certain industries have also defined approach to safety by separating the safety critical functionality from other functionality. Typically, in these the approach is such that the system needs to ensure the safety critical functionality to work with desired likelihood and the other functionality to not interfere with the safety critical functionality. Qt is well suited for this type of an approach, and we also have a certified solution to the safety critical functionality: https://www.qt.io/product/functional-safety-and-qt As a large framework Qt is not directly created for approach where it alone needs to provide a safety critical functionality without any support from the system architecture (noting that the Qt Safe Renderer is specifically created for this purpose). Anything is possible, but our recommendation is to approach the topic from system design viewpoint. Separating the safety critical functionality and creating a viable approach for it. If Qt libraries are used without such separation by the system, it requires extensive testing of the exact functionality used (both for Qt framework and the application). It should be noted that while there are many similarities, multiple industries have also defined their own approach to functional safety. With Qt Safe Renderer we are directly addressing: IEC 61508, IEC 62304, ISO 26262 and EN 50128. Check details from the link above, if interested. Other ones can be also addressed leveraging the material created during the certification process, but requires additional steps. While you are free to discuss the creation of safety critical systems via the Qt project mailing lists, in case you or someone are planning to create one, would be better to discuss with our functional safety experts and leverage items that are part of our commercial offering. Yours, Tuukka From: Interest on behalf of Ulf Hermann Date: Saturday, 2. October 2021 at 18.15 To: interest@qt-project.org Subject: Re: [Interest] Qt 5.15 LTS vs Qt 6.2 LTS > 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 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
