Re: [Development] Nominating Sami Varanka as an approver

[Eskil Abrahamsen Blomfeldt via Development]

+1 🙂

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics Engines

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Tomi 
Korpipää via Development 
Sent: Wednesday, September 11, 2024 9:22 AM
To: development@qt-project.org 
Subject: [Development] Nominating Sami Varanka as an approver

Hi,

I'd like to nominate Sami Varanka for approver status. He has been working with 
QtGraphs from the beginning and was the one to start the work for it from 
scratch, as a part of his master's thesis. He has been active in fixing bugs 
outside of his own comfort zone during bug fix weeks. He is also the 
co-maintainer for the QtGraphs module.

You can see his dashboard here: 
https://codereview.qt-project.org/q/owner:sami.vara...@qt.io
And his reviews here: 
https://codereview.qt-project.org/q/reviewer:sami.vara...@qt.io

Br,


Tomi Korpipää

Senior Manager, R&D

The Qt Company Oy
Tutkijantie 4C
90590 Oulu
Finland

tomi.korpi...@qt.io

+358445312522

www.qt.io

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right_2023-03-01-095511_zhlr.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png] 
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
 
[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] Minor cmake API change in Qt Wayland 6.8

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

We recently found an issue with Qt Wayland Compositor after upgrading to 
libwayland 1.23, which causes any Qt client to crash as it connects to it. To 
fix this, we need to add a small last-minute API addition to a cmake function 
in Qt Wayland Compositor: 
https://codereview.qt-project.org/c/qt/qtwayland/+/582471 and taken into use in 
https://codereview.qt-project.org/c/qt/qtwayland/+/582472

It will not affect any existing users of the API, since it's optional and the 
default stays the same.

Any suggestions/objections, please comment on gerrit 🙂

Note that the same issue is also present in kwin, and they will make the 
equivalent change there.


--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines



The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io



The Future is Written with Qt

--


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Behavioral change with font metrics

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

I have a pending change which I would like to get into Qt 6.8 which will change 
default line heights of fonts in some cases, so I thought I would mention it 
here to hear if people have objections. Since it does change text layouts in 
some cases, it also adds a fallback mechanism to previous behavior, both per 
font with a style strategy in QFont and an application attribute. Some users 
will notice this and manually have to change their code if they are unhappy 
with the changes, but in practice it is a correctness fix.

https://codereview.qt-project.org/c/qt/qtbase/+/563751

Background is this:

In OpenType fonts there are three different sets of metrics providing the 
vertical metrics of the font

  *
The ascender/descender/lineGap in the HHEA table (predates OpenType)
  *
The winAscent/winDescent in the OS/2 table
  *
The typoAscender/typoDescender/typoLineGap also in the OS/2 table

Microsoft's approach is typically to add new fields to OpenType rather than 
risk breaking legacy software, so the format is kind of convoluted due to this. 
In most fonts the HHEA values will match the typo* values, but older 
implementations of the font system had platform-specific handling of these (as 
the spec says), so to ensure backwards-compatibility, Microsoft added the 
additional sets.

The winAscent/winDescent are used for clipping the glyphs, so they need to be 
set so that no glyph in the font is higher than winAscent+winDescent. Often the 
sum will match typoAscender-typoDescender+typoLineGap, but not always. The 
clipping requirement makes them less suitable for typography, since there's no 
way to add e.g. glyphs that are taller than the line height of the font. But 
many applications still used winAscent+winDescent for line heights, including 
Microsoft's own GDI. So to make it possible to keep the default of 
winAscent+winDescent for existing fonts but still allow fonts to expand beyond 
this, they later added the USE_TYPO_METRICS flag to the OS/2 table, which is 
supposed to be set if the typo* metrics are valid to use.

In Qt 5 we would have platform-specific handling of this:

  *
Windows would use winAscent+winDescent as default, unless USE_TYPO_METRICS was 
set, in which case the typo* metrics were used
  *
FreeType would use the typo* metrics if available
  *
macOS would use the original metrics in HHEA, even if the OS/2 table is present 
in the font, typically matching the typo* metrics.

Users were complaining about inconsistent layouts between platforms, and in Qt 
6.0 we tried to consolidate, by making all platforms use the OS/2 data if 
available, and prefer typo* metrics if the USE_TYPO_METRICS was set and win* 
metrics if not.

We early found out that this was not a viable plan on macOS, because some fonts 
that are only used on macOS have OS/2 tables with invalid data in them. So we 
changed macOS to use the platform values again instead. This typically matches 
the typo* values granted that those are set correctly, because there is no 
reason for these to be different. But we kept the changed default on FreeType, 
so that this now matches Windows.

Some recent discussions has made me regret this decision, though. The OpenType 
spec
 very clearly states:

Some legacy applications use the usWinAscent and usWinDescent values to 
determine default line spacing. This is strongly discouraged. The sTypo* fields 
should be used for this purpose.

So despite GDI choosing the backwards compatible route, the recommendation is 
to always use the typo* metrics for line spacing. This means that modern font 
systems that are not limited by compatibility concerns will use this, and this 
in turn means that fonts will be designed with this in mind. Font designers 
will often neglect to set the USE_TYPO_METRICS flag even if the typo* metrics 
are preferable, because the fonts work fine on FreeType and DirectWrite 
applications.

Now, the conservative approach would be to do what Microsoft did and keep the 
current default + add an opt-in for the correct behavior. But I fear becoming a 
primarily compatibility-driven toolkit can be inhibiting, like it is for GDI, 
so I would rather like to default to correctness, following the recommendation 
in the spec and introduce an opt-out for those users who want to get back the 
original behavior.

So that's what my change currently does. By default, macOS will still use HHEA 
(so font designers still need to make sure those are in sync with the other 
metrics) but Windows and FreeType will both now prefer the typo* metrics, even 
if the USE_TYPO_METRICS flag is unset. If PreferLegacyLineMetrics is set, then 
all platforms (including macOS) will use typo* metrics if USE_TYPO_METRICS is 
set and win* metrics otherwise, granted that the OS/2 table exists in the font. 
(I think changing macOS to correspond to the others here is ok, since it's a 
manual opt-in.)

Some users will see that t

Re: [Development] Nominating Jøger Hansegård for approver rights

[Eskil Abrahamsen Blomfeldt via Development]

+1 🙂

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Thursday, March 14, 2024 10:06 AM
To: development 
Subject: [Development] Nominating Jøger Hansegård for approver rights

Hi,

I would like to nominate Jøger Hansegård for approver rights in the Qt project.

Jøger joined The Qt Company 10 months ago and has since then been getting his 
hands dirty in Qt Multimedia, and lately focusing on color management.

Jøger is a thorough and responsible engineer and I trust that he will make a 
good approver for the Qt project.

Authored changes: 
https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io

Cheers,
Tor Arne
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

I would like to nominate Hatem ElKharashy for maintainership of the Qt Svg 
module. This module currently does not have any active maintainer, but it has 
been part of my team's responsibility and backlog within The Qt Company.

Hatem has recently been working on adding support for new SVG features in Qt 
Svg, as well as fixing bugs and greatly improving the test coverage in the 
module. I think he is a great candidate to take on the maintainership of this 
module.

Authored changes:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io

Reviewed hanges:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io


--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines



The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io



The Future is Written with Qt

--


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Piotr Wierciński for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1 🙂

Although I think 2013 should be 2023.

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Morten 
Sørvig via Development 
Sent: Thursday, February 8, 2024 9:39 AM
To: development@qt-project.org 
Subject: [Development] Nominating Piotr Wierciński for approval status

I would like to nominate Piotr Wierciński for approver rights in the Qt project.

Piotr joined the Qt company early 2013 and has since then contributed to Qt for 
WebAssembly. This includes many bugfixes and also larger efforts such as 
getting tests running in the CI system.

Piotr is a pleasure to work with and I trust that he will make a good approver 
for the Qt project.

Changes:  https://codereview.qt-project.org/q/owner:piotr.wiercinski
Reviews:  https://codereview.qt-project.org/q/commentby:piotr.wiercinski 


Best regards,
Morten
--
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] Nominating Hatem ElKhrarashy for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1 🙂

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Janne 
Koskinen via Development 
Sent: Tuesday, February 6, 2024 10:18 AM
To: 'Qt development mailing list' 
Cc: Hatem ElKharashy 
Subject: [Development] Nominating Hatem ElKhrarashy for approval status

I would like to nominate Hatem Elkharashy for approver rights in the Qt project.

Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, 
QtCharts, QtDeclarative, QtBase and most recently on QtSvg.

Changes where he is the author:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io

Changes where he is reviewer:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io

-Janne Koskinen
--
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] Nominating Vlad Zahorodnii for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of David 
Edmundson 
Sent: Thursday, February 1, 2024 3:11 PM
To: development 
Subject: [Development] Nominating Vlad Zahorodnii for approval status

I would like to nominate Vlad Zahorodnii for approver rights in the Qt project.

Vlad has also been working on the QtWayland backend, providing insight
based on his other role as one of the kwin maintainers.
Vlad and I have been working together at Blue Systems for 5 years. He
is extremely technically competent and very thorough in reviews. I
trust that he would exercise approver rights responsibly.

Changes where he is the author:
https://codereview.qt-project.org/q/author:vlad.zahorodnii%2540kde.org
Changes where he commented/voted
https://codereview.qt-project.org/q/reviewer:vlad.zahorodnii%2540kde.org
--
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] Nominating David Redondo for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of David 
Edmundson 
Sent: Thursday, February 1, 2024 3:10 PM
To: development 
Subject: [Development] Nominating David Redondo for approval status

I would like to nominate David Redondo for approver rights in the Qt project.

David's first contributions to Qt started in November 2020, but has
ramped up this last year working on the Qt Wayland platform. Not only
has he fixed a lot of issues within Qt Wayland, but he has also
managed to push changes into upstream wayland and un-break a lot of
important Qt functionality.
David and I work together at Blue Systems for the last 4 years. I have
full confidence in his ability to review code correctly and also to
use any new privileges appropriately.

Changes where he is the author:
https://codereview.qt-project.org/q/author:qt%2540david-redondo.de
Changes where he commented/voted on:
https://codereview.qt-project.org/q/reviewer:qt%2540david-redondo.de

David
--
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] Nominating Matthias Rauter for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Paul Tvete 
via Development 
Sent: Tuesday, January 30, 2024 1:11 PM
To: Qt development mailing list 
Subject: [Development] Nominating Matthias Rauter for approval status

Hi,

I would like to nominate Matthias Rauter as an approver for the Qt Project.

Matthias has been working on Qt for more than a year now. In this time, he has 
done great work on Qt Location and Qt SVG, among other. I have had the pleasure 
to work with him on the Curve Rendering project in Qt Quick Shapes where he has 
made impressive contributions. He has been consistently professional in 
development and review, and I am certain that he will exercise his approver 
powers responsibly.

List of changes made by Matthias: 
https://codereview.qt-project.org/q/owner:matthias.rauter%2540qt.io
Matthias's review activity: 
https://codereview.qt-project.org/q/commentby:matthias.rauter%2540qt.io

Cheers,
 - Paul
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Replacement for QFont::ForceIntegerMetrics in Qt 6?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

ForceIntegerMetrics was originally added to get CoreText to look at little bit 
better with WebKit, since WebKit did not support subpixel positioning at the 
time and CoreText did not support font hinting. I removed it in Qt 6 because 
it's honestly not a typographically sensible thing to do, and the original use 
case had become irrelevant 🙂

For your case, where you want to make sure your font aligns to the pixel grid, 
you could try enabling hinting  on it with 
font.setHintingPreference(QFont::PreferFullHinting). Font hinting will slightly 
alter the glyphs so that they actually align to the pixel grid instead of 
introducing kerning errors (which is what ForceIntegerMetrics did). I'm not 
sure if this is what you mean by "disabling design metrics"? If so, what 
exactly was the issue with it? I principle, I think this is the most correct 
solution to the problem, so maybe there's some way of getting it to work.

If that does not work, then another option is to manually get the QGlyphRuns 
from the QTextLayout and align the glyphs yourself before drawing them. That 
should get you the same layout as with ForceIntegerMetrics, both good and bad, 
without much extra work.

(Of course, ideally the rendering code should not assume integer advances for 
the characters, since this is not really a reasonable expectation for unhinted, 
scalable fonts, but I can see how it's not tempting to rewrite it just for this 
port.)

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Kai Uwe 
Broulik 
Sent: Saturday, November 4, 2023 10:50 AM
To: development@qt-project.org 
Subject: [Development] Replacement for QFont::ForceIntegerMetrics in Qt 6?

Hi everyone,

in Qt 5.15 the QFont::ForceIntegerMetrics was deprecated and
subsequently removed in Qt 6.

The rendering engine in Konsole, KDE’s terminal emulator, relies on the
fact that every glyph in the monospace font is rendered at the same
width, since sections of different style (e.g. search highlight, text
selection, various escape sequence formattings, etc) are painted in
different pases, basically positioned at charWidth * letterXPos.

With Qt 6, without this flag, the individual letters might be placed at
fractional positions, so a long text run can end up short of what the
renderer expects, leading to gaps in the rendering, see the attached
screenshot where I selected some text which now makes a gap.

I have read into QFontEngine a bit and found that the general
replacement is disabling use of “design metrics”. I changed the
rendering to use QPainter::paint with a QTextOption disabling design
metrics [1], which fixed the issue on my machine but apparently causes
issues with other fonts again.

Many of us have tried to find a solution for this but haven’t, really,
and it is a major showstopper for the Qt 6 adoption here. Any idea how
to address this properly, short of rewriting the renderer that I assume
has been like this for decades or perhaps some insights on what prompted
the removal?

Cheers
Kai Uwe

[1] 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Finvent.kde.org%2Futilities%2Fkonsole%2F-%2Fmerge_requests%2F911&data=05%7C01%7Ceskil.abrahamsen-blomfeldt%40qt.io%7C402caffbb31d49df5cef08dbdd1bc085%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638346883796105023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c5whMadCyHEavgFDTdDha8dTpO%2FRUBAnK%2Bp453ynvmk%3D&reserved=0
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QSGText: Why round glyph position like this?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

Just removing the pixel snapping from the vertex shader should definitely cause 
regressions, yes.

I'm not totally clear on what the problem is on your end, so maybe it is more 
efficient if you file a bug report for this with some screenshots and 
descriptions of what you mean?


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Kai Uwe Broulik 
Sent: Tuesday, September 5, 2023 8:51 AM
To: Eskil Abrahamsen Blomfeldt ; 
development@qt-project.org 
Subject: Re: [Development] QSGText: Why round glyph position like this?

Hi,

thanks for your insights, Eskil!

I am running a self-compiled Qt dev, so it’s all up-to-date. I did some
further investigation and found that the glyph cache is actually
rendered alright, so nothing to do with FreeType etc.

It seems that the textmask.vert [1] shader is still not entirely
perfect, even after the fixes you mentioned: If I remove the
flooring/dpr stuff from it, text is rendered correctly here but could
probably regress elsewhere?

For example, the word “Erscheinungsbild” has two “i”, both use the same
glyph in my case, but the second one is rendered incorrectly by the shader:

Glyph #7 (i):
In cache at 66,1 @ 5x17, gets rendered to 40.5714,4 @ 2.85714x9.71429
Scale the coordinate back up x1.75 gives us 70.5,7 @ 4.95x17.075

Glyph #14 (i):
In cache at 66,1 @ 5x17, gets rendered to 90.2857,4 @ 2.85714x9.71429
Scale the coordinate back up x1.75 gives us 157.75,7 @
4.95x17.075

I haven’t managed to get Renderdoc up and running, though, to see what
values the shader actually processes and why one gets misplaced by it.
Any idea?

The issue can be reproduced under Wayland *and X*, with NativeRendering.

Cheers
Kai Uwe

[1]
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/shaders_ng/textmask.vert#n22

Am 29.08.23 um 13:07 schrieb Eskil Abrahamsen Blomfeldt:
> [...] I did fix some bugs related to this,
> e.g. https://codereview.qt-project.org/c/qt/qtdeclarative/+/417675
>  and
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/376361
> 
>
> Most of my testing was on Windows, though, so it sounds like there could
> still be issues on Wayland
> [...]

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QSGText: Why round glyph position like this?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

The reason for rounding is that the subpixel position of the glyphs is baked 
into the cached rendering of the glyph itself (so horizontal position x.5 would 
be a different cached object than x.0, but they should both be rendered at 
pixel x). It's a bit complex because the projected positions of the glyphs are 
calculated later, in the vertex shader, so you need to do some precalculation 
to produce something which aligns with the pixel edge when the final scale is 
applied. I believe the reason retina is mentioned there specifically is just 
because it's the first place we supported DPI-scaling, but it's not exclusive 
to Apple anymore.

Which Qt version is in use here? I did fix some bugs related to this, e.g. 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/417675 and 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/376361

Most of my testing was on Windows, though, so it sounds like there could still 
be issues on Wayland.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Development  on behalf of Kai Uwe 
Broulik 
Sent: Monday, August 28, 2023 6:22 PM
To: development@qt-project.org 
Subject: [Development] QSGText: Why round glyph position like this?

Hi everyone,

while investigating blurry font with native renderer in QML apps in
Plasma 6 under Wayland with fractional scaling (devicePixelRatio 1.75 in
my case), I stumbled upon QSGTextMaskMaterial::populate which rounds the
glyph position [1] citing Mac OS behavior.

When I remove the rounding, font appears rendered correctly on my system
(sorry for attachment ;), but this code hasn’t changed since 2014 and I
am not very knowledgeable in this part of Qt. It’s also flooring the X
and rounding the Y coordinate.

What’s the deal with that? Tor Arne, can you perhaps shed some light on
this?

Cheers
Kai Uwe

[1]
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/qsgdefaultglyphnode_p.cpp#n455
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWayland compositor can't to render a wl_surface to multi outputs, Is this a restrict of QtQuick graphics scene?

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

Each window has an isolated scene graph and RHI instance, which is the reason 
for this limitation if I understand correctly. Decoupling them is actually 
quite complicated, because different screens have different surface formats 
requirements and it might not be possible to render to both screen within the 
same context or to share graphics resources between them. These difficulties 
are also why Wayland Compositor bases outputs on windows with isolated 
graphics. I know there have been talks of decoupling the Qt Quick graph from 
the window, so that the same Qt Quick code can control items in multiple 
windows. There would still be separate graphics for the two windows and then 
need for duplicate items, but synchronizing animations in that case should be 
easier. Nothing concrete has come of this yet, though, but to me it sounds like 
a more feasible way forwards than redesigning the Qt Quick scene graph.

In the current state, duplicating the items is the correct way to go, at least. 
In order to make sure the animations are in sync, you could for instance have 
some centralized property in a singleton which is read from both scenes and 
just animate that. I think that's probably the easiest way.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Development  on behalf of JiDe Zhang 

Sent: Tuesday, July 4, 2023 9:06 AM
To: Qt邮件列表 
Subject: [Development] QtWayland compositor can't to render a wl_surface to 
multi outputs, Is this a restrict of QtQuick graphics scene?

The following is a part of an QtWayland example:

WaylandOutput {
sizeFollowsWindow: true
window: Window {
width: 1024
height: 768
visible: true

Repeater {
model: shellSurfaces

ShellSurfaceItem {
shellSurface: modelData
onSurfaceDestroyed: shellSurfaces.remove(index)
}
}
}
}


If I have two displays, and a part of a ShellSurfaceItem is in the first 
display, and the other part of the ShellSurfaceItem in the second display. In 
this case, I need to ensure the user can see this ShellSurfaceItem
on both first and second displays, on QtWayland, I can using two WaylandOutput 
with two Window for this case, and create ShellSurfaceItem for which 
WaylandOutput.

But, If I using two ShellSurfaceItem for one wl_surface, I can't sync the 
window animation in different WaylandOutput, this is a hard job, because the 
QQuickItem must bind to single Window, it's can't render to multi Windows.

The better way is redesign QtQuick scene graphics, like as:


  1.  Add QQuickScene class to instead of a part of functions of QQuickWindow. 
a QQuickItem must be added to a QQuickScene, a QQuickScene is a coordinate 
system.
  2.  Add QQuickViewport class, and allow attach multi QQuickViewport to one 
QQuickScene. the QQuickViewport be responsible for render QQuickItem to target 
output. And allow the QQuickViewport can render in a new thread(be different 
than the other QQuickViewport in same QQuickScene).
  3.  Add QQuickRenderTarget::fromSurface(EGLSurface/VkSurface) functions, and 
using QQuickRenderTarget to QQuickViewport::render(QQuickRenderTarget target).
  4.  The QQuickWindow don't depends on QSG* class, it can wapper 
QQuickViewport and QQuickRenderTarget to render QQuickItem.
  5.  Add QQuickSceneHelper abstract class, The QQuickWindow event dispense to 
QQuickSceneHelper, and QQuickSceneHelper dispense event to QuickItem. Provide 
like as "virtual QQuickSceneHelper::setCursor" functions to instead of 
QQuickWindow::setCursor in QQuickItem::setCursor.
  6.  The QQuickItem without QQuickWindow, using QQuickItem::pixelRatio to 
instead of QQuickWindow::effectiveDevicePixelRatio(), the 
QQuickItem::pixelRatio is only using for load resources(like as 
QQuickImage::load), for the render matrix, using the 
QQuickViewport::devicePixelRatio when rendeing.

The above changes may not change the abi.

If I misunderstand QtWayalnd and QtQuick Scene Graphics, please tell me, thanks.


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Does QSGPlainTexture needs call setHasAlphaChannel on Vulkan renderer?

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

If the texture does not have alpha, that means we can do disable blending, do 
front-to-back sorting to minimize overdraw, and use depth-buffer checks to 
preserve stacking. So in the case where you know there is no alpha, this is an 
optimization. If you do not know whether or not there is an alpha, the safe 
choice is to assume that there is an alpha channel. Even if all the alpha 
values are at 100% opacity, the alpha-blending will still give the right 
results, whereas unblended opaque rendering will only be correct if the texture 
is completely opaque.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


Fra: Development  på vegne av JiDe Zhang 

Sendt: onsdag 26. oktober 2022 10:13
Til: Qt邮件列表 
Emne: [Development] Does QSGPlainTexture needs call setHasAlphaChannel on 
Vulkan renderer?

Hi, I am working for wlroots with Qt. In this 
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3538#note_1604273
  patch, I am exporting some interfaces in wlroots for vulkan, and using it 
with QtQuick, I want to get the has_alpha value of texture, but Simon Ser 
thinks we shouldn't need know has_alpha value of vulkan texture.

If I don't call setHasAlphaChannel for QSGPlainTexture, and if the texture is 
having alpha, then I will see the wrong display effective.

So, Is it a Qt bug? Although I don't think it's a Qt bug, but I can't get has 
alpha of texture from wlroots in vulkan.

How should I do?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development