07:28 wlb: weston/main: Marius Vlad * libweston: Add paint node destruction into weston_layer_entry_remove() https://gitlab.freedesktop.org/wayland/weston/commit/2d3cca3d3e2d libweston/compositor.c
07:28 wlb: weston Merge request !1489 merged \o/ (libweston: Add paint node destruction into weston_layer_entry_remove https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1489)
07:35 jadahl: emersion: i'm going to be on pto 18-25th, but I don't think that's reason enough to have a different schedule so sgtm
07:36 pq: emersion, the release schedule sounds fine by me, but I also don't track anything relevant.
07:38 pq: hmm, Gitlab has started saying for MRs: "Merge blocked: 1 check failed", when the only thing missing is an automatic rebase.
08:24 wlb: weston Merge request !1494 opened by Marius Vlad (mvlad) Backport fixes for Weston 13 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1494
08:44 d_ed[m]: <Company> "zamundaaa: have you ever..." <- We have API for apps to choose between "I want to be integer and scaled by the compositor" or "I'll try and do fractional directly"
08:44 d_ed[m]: but it's API in the app itself, rather than a user facing thing
08:44 d_ed[m]: unless they meddle with env var overrides
08:45 d_ed[m]: We == Qt ^
09:28 emersion: if a color management person is interested, someone sent this https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4634
09:28 emersion: would be great to have feedback on the approach, as i have no idea how to review
09:34 kennylevinsen: When I saw that MR I did end up questioning whether this was a case of the alpha being wrong on the client due to assuming the old blending style, rather than a flaw in the new blending
09:35 kennylevinsen: which in turn made me wonder how other platforms do the same blending, if something akin to transparent subsurfaces/windows are used for the same feature
09:47 wlb: wayland-protocols/main: Simon Ser * tablet-v2: mark as stable https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/72b5d90a024d stable/tablet/README stable/tablet/tablet-v2.xml meson.build unstable/tablet/tablet-unstable-v2.xml
09:47 wlb: wayland-protocols Merge request !284 merged \o/ (tablet-v2: mark as stable https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/284)
09:54 pq: emersion, reading the very first paragraph of the MR description, this sounds like "I am used to blending electrical space, I have tuned all by source color values to look good with that, and your optical blending produces something different."
09:54 pq: *all my source
09:55 pq: blending in different spaces inherently produces different results
09:55 emersion: right but this MR does something different from just blending in electrical space still?
09:56 pq: sure - and luckily Wayland does not define how blending works, so it's up to your compositor policy what you consider "correct" or "best"
09:57 pq: so foremost a policy decision
09:58 emersion: hm
09:58 emersion:still no clue what to do with that MR
09:59 kennylevinsen: Are we still the only ones with a renderer doing optical blending?
09:59 pq: there is no obviously right answer
10:00 pq: weston would do optical blending, if you enabled "experimental, tentative, WIP" color management.
10:01 pq: possibly one might want to limit that MR kind of trickery to untagged wl_surfaces, i.e. those without an image description.
10:01 jadahl: kennylevinsen: I have a branch that makes mutter blend using optical blending *sometimes* (e.g. wayland surfaces)
10:01 kennylevinsen: jadahl: I was just about to ask what the plans were in mutter :)
10:01 jadahl: hard to say if it looks better or worse. its very subjective
10:02 pq: personally I would like to standardise around optical blending, at the very least for all windows with an image description
10:02 emersion: kennylevinsen: gamescope does as well iirc
10:02 emersion: not sure about kwin
10:03 pq: but semi-transparent tooltips? Should they be made semi-transparent by the client or by the compositor?
10:03 emersion: i'm confused
10:04 emersion: the compositor has no say in this
10:04 emersion: the fact that they are semi-transparent, that is
10:04 jadahl: tooltips tend to be just arbitrary xdg_popup's potentially with a non opaque alpha channel
10:04 emersion: yea
10:04 pq: the compositor knows what wl_surface is an xdg_popup, so it could make them all semi-transparent
10:04 jadahl: thats nouds bad
10:04 jadahl: *sounds
10:04 pq: perhaps
10:05 kennylevinsen: If we're more or less all pushing towards optical blending, then I might be vary of workaround like this as the clients are likely to adjust their alpha values to fit optical blending anyway
10:05 pq: but *should* it be in compositor control?
10:05 emersion: yeah, that sounds pretty bad, the xdg_popup might be anything
10:05 emersion: like a popover form
10:06 jadahl: pq: are you saying it should be "make this popup a bit transparent, but expect there to be text so not too much"
10:06 jadahl: ?
10:06 pq: we could extend xdg protocol to label tooltips, then compositors could handle them
10:06 pq: kennylevinsen has an excellent point, for those apps that are maintained
10:07 pq: could Xwayland vs. wayland-native be the divider?
10:08 pq: jadahl, I'm asking whether some DE settings would like to have "make tooltips this much semi-transparent"
10:08 jadahl: in Xwayland its override-redirect windows, that *might* have a tooltip hint, but they might already be a bit transparent
10:08 kennylevinsen: regarding having the compositor decide tooltip appearance - it is an idea if there is a clear enough role, but unless the client is forced to certain color/font parameters, or can know the compositor choices, I fear legibility could be compromised by "surprising" compositor decisions
10:09 emersion: imho clients should remain in control of the theming
10:09 pq: no, I meant: Wayland-native apps likely would get updated, while X11 apps likely would not get updated.
10:09 jadahl: pq: maybe toolkits wants a "make this appear as if it was blenden electrically ish"
10:09 pq: jadahl, then you need a blending protocol extension.
10:09 jadahl: or the reverse, and assume thats the case by default
10:09 jadahl: sure
10:10 jadahl: we need that anyway, for non-opaque subsurfaces and overlay planes
10:10 pq: then you also get to figure out what blending in electrical means, when your framebuffer is HDR
10:10 jadahl: (in planes too)
10:10 jadahl: right..
10:11 pq: personally I'm trying to stay as much away from blending in electrical as I can
10:12 jadahl: hard when *all* blending is that way now in most places :P
10:12 pq: perhaps quirks can be added for "legacy" apps, but how to detect such apps? Wayland-native vs. X11?
10:12 pq: sure
10:12 pq: I have always expected lots of crying
10:13 pq: but it's still the compositor project's policy
10:13 jadahl: crying because of how beautiful HDR is?
10:14 pq: no, people screaming at me I broke their apps
10:15 pq: btw. web browsers have the same problem, and more serious
10:15 kennylevinsen: "my workflow relies on SDR being blown out without tone mapping in HDR mode, please add an option to do the wrong thing"
10:16 jadahl: would have preferred happy crying, but ok
10:16 kennylevinsen: that usually happens in private though
10:21 pq: https://hg2dc.com/2019/07/21/question-9/ is the same dilemma, except it forgets to explain that often which one is "right" is whatever you happen to expect. To me, it looks like there is a light fringe replacing the dark fringe.
10:23 pq: our need to be able to mix SDR and HDR content complicates things
10:30 pq: emersion, if one needs to tweak the optical blending towards what people are accustomed to, I find the proposed algorithm a very sensible one. It modulates transparency, but does not change chromaticity.
10:31 pq: it also makes no assumptions about the blending target, modulating only the source opacity, which is good.
10:32 pq: it remains to be experimented how it looks like on various combinations of colors of destination, popup background, and popup foreground (text)
10:33 pq: it might conflict somewhat with font anti-aliasing
10:34 pq: that's due to using the "lightness" to modulate alpha
10:45 pq: emersion, the middle patch is right about needing to un-premult before decoding by TF.
10:47 emersion: thanks pq!
10:47 emersion: yeah, the middle patch has been merged separately already
10:48 pq: emersion, it's certainly an interesting proposal, and well founded, but I would like to limit its application to "legacy apps", however you want to define that.
10:48 mclasen: pq: the color nerd dilemma - caring deeply about something nobody else gives a hoot about
10:49 emersion: i don't think it makes a lot of sense to differentiate between X11 and Wayland - to me they are in the same boat
10:49 emersion: but color-managed Wayland sure is different
10:49 pq: mclasen, no, people definitely care: people don't want change.
10:49 swick[m]: I really just want everything to be blended in optical
10:50 swick[m]: I don't really care if old apps look a bit off because they have been tuned for electrical sRGB blending
10:50 pq: it does not seem "just a bit off"
10:51 swick[m]: it doesn't become unusable
10:51 pq: I see a significant difference in readability
10:51 alice: is there a visual example floating around
10:51 pq: if someone was struggling before, they probably can't read it after
10:52 swick[m]: okay, sure, but you can either fix it, or change the font size, or change scaling
10:52 swick[m]: the more weirdness we add here the worse it will be in the long run
10:53 pq: I agree on the weirdness causing problems
10:53 pq: blending in optical "breaks" some apps and they need to be fixed, either in the app or by quirking them in the compositor.
10:55 pq: I think that limiting quirking, if it is needed, to untagged surfaces could suffice. I would not want quirking with apps that use color-management extension.
10:56 pq: also, if we expect apps to be fixed, their developers will ask how to detect a compositor that needs the fix
10:57 pq: they do not want to regress their apps where they used to look just fine
11:26 zamundaaa[m]: pq: I'm not 100% sure if differentiating between tagged and untagged surfaces is such a great idea. Toolkits might start using the protocol, and boom apps suddenly look different
11:28 pq: well, yes - why would you do that?
11:28 pq: I mean, they
11:28 pq: sRGB tag does not mean the same as no tag
11:30 pq: sRGB tag says "I am very definitely following the sRGB spec", while no tag says "try to do what has been done before"
11:30 zamundaaa[m]: Qt already has a way to tag images with color spaces afaik. I'd be very surprised if it wasn't tagged as sRGB by default
11:31 zamundaaa[m]: Though I dunno if that extends to windows
11:33 pq: the alternative is a blending method extension with options like "the old-school way" and "optical blending"
11:34 pq: and then we'd add more blending methods as they arise
11:34 zamundaaa[m]: As we need a way for apps to request or at least know if they'll get optical blending, that doesn't sound like a bad idea to me
11:34 pq: optical blending is easy, because we have a clear definition for it
11:35 pq: the old-school way cannot be anything explicit, because HDR, so it might be some approximation like suggested for wlroots
11:35 drakulix[m]: I am not sure want to define the global blending-space though, but the app should at least know how blending in regards to it's own subsurfaces will happen.
11:36 pq: drakulix[m], neither option mentioned here defined a blending space.
11:37 pq: a blending space is a more detailed definition than a blending "method", and even method may allow approximate results
11:37 drakulix[m]: right, space != method. I always get that mixed up.
11:39 zamundaaa[m]: To throw in some practical information about this whole thing, we've had exactly one bug report about linear blending actually causing issues so far
11:40 pq: zamundaaa[m], interesting, what was it, and how widely have people been using optical blending?
11:41 pq: or do they just configure it away if it seems to bother?
11:42 zamundaaa[m]: It was in the logout screen, where with linear blending, text becomes effectively unreadable, if the window has something bright underneath. That problem is effectively caused by the text having too low contrast to begin with, and the background being more transparent just made it worse
11:42 zamundaaa[m]: pq: everyone with an ICC profile or HDR gets linear blending in Plasma 6
11:42 pq: right
11:43 pq: zamundaaa[m], do you have an idea how many people what might actually be? Why would people enable either?
11:43 pq: *that
11:44 pq: In general, what do people even want from window semi-transparency before they go look for the color and alpha values that produce the results they like to see? Is it really per-pixel coverage? Translucency? something else?
11:44 zamundaaa[m]: We've gotten a few bug reports about various minor things with ICC profiles, so some people are using it at least
11:45 zamundaaa[m]: We got more bug reports about HDR being broken in drivers, and lots of Reddit posts along with it, so I think people that have HDR screens are at least testing it pretty widely
11:45 pq: cool
11:46 zamundaaa[m]: pq: it's amost exclusively background transparency to make things look more fancy
11:46 zamundaaa[m]: Usually with blur
11:47 pq: window background see-through?
11:47 zamundaaa[m]: Yes
11:48 zamundaaa[m]: Usually only on desktop environment surfaces and semi transparent terminals, but some users go very far with theming
11:49 pq: That's kind of obvious, thinking about it. But what "material" should a semi-see-through window look like? matte paint on diffuse glass?
11:51 pq: if the material is customizable, then blending cannot be defined more than very vaguely by protocol
11:51 pq: hmm, customizable where, compositor or app...
11:52 zamundaaa[m]: How it works right now with KDE apps is that they explicitly request blur from the compositor
11:52 pq: right
11:52 zamundaaa[m]: We also have a background contrast effect that the shell uses, which can set some parameters to match the theme
11:52 zamundaaa[m]: But I don't think any apps use that
11:52 pq: window shaping is very different from any translucency with blur
11:53 pq: it's like window shaping should be decoupled from translucency, can use the same alpha channel for both
11:53 pq: *cannot
11:54 pq: alpha-as-coverage is shaping
11:55 pq: so it's actually an abuse to use today's alpha channel for window semi-transparency
11:56 pq: non-0 non-1 alpha values should be reserved for anti-aliasing the window shape
11:56 emersion: zamundaaa[m]: how do you implement ICC in the shader btw? only a 3D LUT? or a more complex pipeline?
11:57 zamundaaa[m]: pq: Yeah blur with rounded and anti-aliased edges is a problem. It's not *that* noticeable, but it's an issue
11:57 zamundaaa[m]: emersion: it's some matrices, two 1D luts and a 3D lut right now
11:57 emersion: and you manage to fill that from the ICC profile?
11:58 zamundaaa[m]: https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/drm/icc.frag?ref_type=heads
11:58 emersion: what happens when the profile doesn't match this model?
11:58 zamundaaa[m]: emersion: I use the BToA tag, it's defined to match that or some combination of these steps
11:59 emersion: zamundaaa[m]: specifically it could be multi element process?
11:59 zamundaaa[m]: I'd like to have a more generic color pipeline shader, but haven't gotten around to making it yet
11:59 wlb: weston Merge request !1495 opened by Naveen Kumar (NaveenKumar) Re-enable atomic tearing capability support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1495
11:59 pq: BToA cannot be MPE, IIRC
11:59 pq: BToD can
11:59 zamundaaa[m]: Indeed
12:00 emersion: right
12:00 pq: then there are the matrix-shaper style profiles using completely different tags providing exactly 3 curves and one matrix
12:01 emersion: zamundaaa[m]: btw, the decoding part of lbicc is done
12:01 emersion: libicc*
12:02 pq: emersion, you weren't scared by Graeme's and Marti's comments of decades of accumulated workarounds for faulty ICC profiles that people want to use? :-)
12:02 emersion: zamundaaa[m]: so if both BToA and BToD are provided, you pick the BToA?
12:02 zamundaaa[m]: emersion: yes
12:03 pq: ICC spec gives the preference order, but it is conditional on what you support, so...
12:03 emersion: okay, that does make it easier (at the cost of precision)
12:06 emersion: pq, not yet
12:08 pq: I never got an answer to my question "Are all ICCv4 matrix-shaper profiles without the ?To?0 tags broken by ICC's definition?" :-p
12:08 emersion: pq, the broken ICC files i found, lcms2 couldn't parse them either
12:09 pq: "the" broken files?
12:09 emersion: x11-colors.icc from colord is one of them, for instance
12:10 emersion: has a broken M curve array in BToA
12:10 pq: interesting, but I was thinking more of the pieces of code I found inside LittleCMS to deal with not-quite-right profiles.
12:10 emersion: (was confused for a bit because lcms2 delays parsing until the last moment)
12:10 emersion: yeah
12:11 pq: like what is the black point
13:22 wlb: wayland-protocols Issue #188 closed \o/ (xdg_surface window geometry calculation https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/188)
15:15 wlb: weston Merge request !1496 opened by Derek Foreman (derekf) xcb-client-helper: Call xcb_wait_for_event directly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1496 [Testing]