ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<kennylevinsen>
ah I get what you mean now, but definitely not
JakeSays has quit [Ping timeout: 480 seconds]
<outfoxxed[m]>
seems odd that they just pile up in a corner
<outfoxxed[m]>
granted bouncing all around the screen isn't amazing either but its better than that
<kennylevinsen>
I disagree - if they changed their growing direction each time they hit a screen edge, the end-user would have a harder time assuming where a next popup would appear
<outfoxxed[m]>
but is that worse than having a bunch of them stacked on top of eachother in a corner
<outfoxxed[m]>
though hopefully nobody has enough nested menus for this to actually be a problem
<kennylevinsen>
You would also stack on top if you had a nested setup that zig-zagged across the entire screen
<outfoxxed[m]>
you'd have to go all the way around the screen before that happens though
<kennylevinsen>
And I think it's easier for users to reason about "Grows to the right like always unless there's no room" is easier than "grows to the right unless an odd number of ancestors hit constraints"/"unless the last ancestor that hit a screen edge hit the right one"
<kennylevinsen>
You don't have to go all the way around - have the first constraint be on the third popup level and you're overlapping with the first popup
<kennylevinsen>
*first hit constraint
<outfoxxed[m]>
yeah I guess its just preference
<kennylevinsen>
deep nested popups flipping around is going to be bad UX anyway, so I prefer at least keeping it simple :)
<jadahl>
iirc gtk will flip the direction of the constraints rule when the direction change
<jadahl>
so it'll bump between the screen edges
Company has joined #wayland
<jadahl>
or maybe not, or maybe that was gtk3
mripard has quit [Remote host closed the connection]
<jadahl>
seeems to be only gtk3 menus that switch direction at the screen edges
ShapeShifter499 has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 480 seconds]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
riteo has joined #wayland
Company has quit [Read error: Connection reset by peer]
latex has quit [Quit: WeeChat 4.2.1]
kts has joined #wayland
paulk has quit [Read error: Connection reset by peer]
paulk has joined #wayland
Company has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
mripard has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
latex has joined #wayland
Company has quit [Read error: Connection reset by peer]
<JoshuaAshton>
It's worth noting that this is also a VkColorSpace and gl_colorspace that is very commonly used, and developers will expect it to exist.
kts_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
<Company>
JoshuaAshton: btw, do you know what format/colorspace macOS composites in?
<Company>
I tried figuring that out after I learned that Windows uses scrgb after reading about in your MR
<Company>
but couldn't find any info about it
feaneron has joined #wayland
<JoshuaAshton>
I have no idea, I imagine it's just some FP16 format. What the primaries are and values represent in terms of luminance are in that format doesn't really matter as it's just an implementation detail. It all ends up as HDR10 anyway =P
<JoshuaAshton>
In terms of applications, for UI stuff, it's their own EDR format, where 1.0 = max sdr brightness and above that is the hdr headroom
rasterman has quit [Quit: Gettin' stinky!]
<Company>
it was mostly about what colorspace I want to make GTK composite so that the mac compositor doesn't have to transform it again
<Company>
and Apple was big on dci-p3 in the past, but I do not know if they built hardware explicitly targeting it
feaneron has quit [Quit: feaneron]
<Company>
and all the hardware I own wants BT2020
<Company>
(or srgb of course)
<JoshuaAshton>
it's always going to need some transformation, you're talking about potentially saving two fmas and a dot product at the composition time, that probably won't be saved anyway cause the compositor is just going to pass some matrix in =)
<JoshuaAshton>
or potentially not even that if it uses a LUT
<JoshuaAshton>
we use a 3D LUT for all our color xforms on Deck, so everything is the same cost regardless of what you do
<Company>
you're thinking full-screen or compositor, I'm thinking application
<Company>
that wants to make life as easy as possible for the compositor
<Company>
so that it can ideally glBlitFramebuffer() from my buffer to the target
<JoshuaAshton>
There is like no case where you can do that with actual color management going on
feaneron has joined #wayland
<JoshuaAshton>
and definitely no case where it is consistent across different displays/output modes/etc
<Company>
yeah, but I can change what my app does on different displays/outputs modes
<zamundaaa[m]>
Company: does the MacOS API not have something similar to the Wayland preferred image description?
<Company>
I'm just trying to make the compositor happy, because happy compositors like my apps
<Company>
zamundaaa[m]: I don't know enough about macOS to know where to even look for it - and the people I asked didn't know
<Company>
the windows people I know found the one paragraph on MSDN where it's explained - I wouldn't have found that one either
<Company>
windows uses fp16 scrgb-linear, which makes a lot of sense
<Company>
because for backwards compat, you can treat srgb apps with GL_SRGB
<Company>
without any extra work to do in shaders while compositing
<zamundaaa[m]>
It doesn't really make any difference
<Company>
depends on what you run it on I suppose
<zamundaaa[m]>
No, the fp16 framebuffer is the performance bottleneck, a single matrix multiplication doesn't hurt when you need to apply an EOTF in a shader anyways
Brainium has quit [Quit: Konversation terminated!]
coucouf1 has joined #wayland
<Company>
do you need to though?
<Company>
with GL_SRGB you don't have an eotf
<Company>
that only works for opaque content, but most of the content of an app is opaque
<Company>
or do you mean on the other end, when going from compositing to kms?
* Company
always confuses eotf and oetf and eotf^-1 and ootf and I've even seen eetf mentioned
<zamundaaa[m]>
Company: you do have an eotf with GL_SRGB, it's just applied in hardware. IIRC on older hw it's limited to 8 bits per color, and that's where running a shader matters
<Company>
zamundaaa[m]: yeah, but 8bits per color is exactly what you are gonna get with backwards compat code
<Company>
and afaik it's implemented as a table lookup, a float[256] - one for linear, one for srgb
<Company>
and I've tested it with linear compositing in GTK, and it's almost zero performance difference if I read/write via GL_SRGB or not
<zamundaaa[m]>
Right, I read that outside of exclusive fullscreen, win32 was also limited to 8 bits per channel for the longest time. So that does make some amount of sense
<Company>
I might remember it somewhat wrong, it might have been measurable, but I decided it's fast enough to allow switching to linear compositing
<Company>
my low end target is rpi4 hardware
<Company>
my goal of how things are going to work is that we switch to linear compositing in GTK, and depending on the compositor, we either hand it GL_SRGB U8 buffers for backwards compatibility, so they see the same they see before
<Company>
or we render to FP16 linear scrgb
<coucouf1>
Dear waylanders, we have freezes with wayland 1.23 + Plasma 5 in Debian
<Company>
and then the compositor gets to do its own linear stuff on top of it