08:19 wlb: wayland-protocols Merge request !313 opened by Jonas Ådahl (jadahl) frational-scale: Don't hard code denomainator https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/313
08:47 YaLTeR[m]: I imagine you still need to deal with the problem from ^ with integer scaled clients, i.e. 1366x768 size and 3x scale
08:57 jadahl: integer scaled clients are less of a problem because scaling down a lot usually looks better than scaling ever so slightly
09:20 Company: it's an interesting question btw how much "slightly" is
09:21 Company: ie if it's better at 175% to integer-scale to 300%
09:21 Company: because 200% is too close to 175% to cause blurriness
09:21 wlb: weston Issue #912 closed \o/ (VNC Screen share disables local touch screen https://gitlab.freedesktop.org/wayland/weston/-/issues/912)
09:22 Company: but I don't even know how many apps that support 200% can actually deal with 300%
09:22 Company: like, I don't think GTK3 properly deals with 300%
09:33 jadahl: I accidentally made GTK4 deal with 1750% and it worked
09:40 Company: I suspect icons may be blurry with GTK3
09:41 Company: GTK 4.16 is a lot better in that respect
09:41 Company: 4.14
09:41 Company: but even before it should be good enough to deal with integers >2
09:44 Company: the magnifier in the GTK3 inspector blurs icons if I grow the size - but that might just be because it reuses the texture as-is
09:45 Company: nope, seems to work
09:45 Company: seems we include and use SVGs everywhere once you go larger
09:47 Company: also good that settings is adaptive, so I can get at the scale dropdown with a 960x600 resolution
09:49 Company: jadahl: was your plan to keep 240/137 as a valid scale in the future?
09:50 Company: because the panel is currently 52px (device pixels) high at 175%
09:51 Company: and 137px would be the first one where a maximized application would get a proper height
09:54 Company: because I would think it's better to just "resize" the output to 3836x2394 and use 175% exactly
09:56 Company: (i would probably not offer 175%, but assuming you want to do that I'd prefer this solution)
10:01 jadahl: Company: what you're asking is to not allow fullscreen windows to be actually fullscreen
10:02 jadahl: also, with 1.75 exactly, it'd be 2400/1371, and the output would be 3840/2399
10:03 jadahl: but that is what the protocol requires already
10:04 Company: jadahl: I'm saying that not being fullscreen exactly is preferrable to weird scales, yes
10:04 Company: though it'd be fullscreen in the Wayland sense - it'd cover the whole output
10:05 jadahl: so that clients get a higher chance of neat alignment?
10:05 Company: it'd just not cover the whole hardware
10:05 Company: yeah
10:05 kennylevinsen: I would personally prefer true fullscreen, just couldn't get it to work reasonable with a "buffer = logical size * scale" approach
10:05 Company: not just clients - compositors, too, for panels and aligned windows
10:05 jadahl: I don't think "higher chance" is good enough. clients should handle the case where it's not lucky and align things internally
10:05 jadahl: one shouldn't have to micro manage a window position or size to get decent results
10:06 jadahl: kennylevinsen: it works if 'scale' isn't limited by /120
10:07 kennylevinsen: jadahl: I'd have to visualize the pixel grid misalignment from integer content to see
10:07 kennylevinsen: unfortunate grid alignments can make things... bad
10:09 kennylevinsen: assuming no bugs in hidpi, that part "should" handle it fine - but might take some adjustment to get all the accidental rounding errors sorted
10:17 Company: you also get fun things like subsurface alignment
10:17 jadahl: subsurfaces are not supported anyway
10:17 jadahl: perhaps they can be if we positioned them in the physical pixel grid of the parent instead of logical
10:17 Company: I was assuming they should be supported at some point
10:18 kennylevinsen: (I'm also not entirely sure what the effect on intermediate window sizes would be with extremely poor pixel grid alignments)
10:18 Company: for popovers exact alignment doesn't matter much
10:18 Company: for graphics offload you get seams
10:19 kennylevinsen: popovers should also be xdg-popups, no?
10:19 jadahl: "wl_subsurface.set_coordinate_space(BUFFER)" then hav set_position be in buffer coordinates
10:19 Company: but graphics offload needs special care anyway, though it's gonna be a bitch to come up with an API that gets 0.5708333... correct without ever getting rounding errors
10:20 Company: kennylevinsen: yeah - when I said subsurfaces, I meant non-toplevels, ie everything that's relative
10:20 Company: kennylevinsen: I assume wl_layer_shell has that problem, too, where the layer should touch maximized windows without seams
10:20 kennylevinsen: jadahl: that's sort of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/149/diffs
10:21 Company: that's also not perfect
10:21 kennylevinsen: agreed
10:21 Company: because sometimes you want application coords and sometimes you want device coords
10:22 Company: even for the same thing, depending on use case
10:22 kennylevinsen: Hmm, I don't think the API needs to expose both simultaneously
10:23 jadahl: right, you still want "surface" coords to make sense because they reflect the size they appear to the human
10:23 Company: I would think the best solution would be to allow fractions for all those application space coords
10:23 kennylevinsen: You need to do a calculation to map from the applications' logical coordinate space to the buffer coordinate space, and if you can do the calculation in one place I don't see why you need the compositor to do it for you for other things
10:23 Company: but that doesn't work without breaking API everywhere
10:24 Company: kennylevinsen: the problem is that you have integers - and sometimes you want an integer amount of device pixels and sometimes an integer amount of application pixels
10:26 kennylevinsen: yeah but the application cannot avoid having to do the math to be able to render its UI, so from my perspective that mapping must already be solvable in the client
10:26 Company: like when playing a 1920x1080 video on a 1/752... scale factor on a 3840x2400 screen, you exactly know where to put the video in device pixels
10:26 Company: but you need to place and size it in application space
10:26 kennylevinsen: having APIs in multiple coordinate spaces for the same client would just move the calculation to the compositor
10:26 Company: *1.752... scale factor
10:27 kennylevinsen: 1/752 scale, gotcha :D
10:27 zamundaaa[m]: Company: if you want to go from the scaled coordinate grid to logical coordinates, the app can just divide the values by the scale
10:27 Company: zamundaaa[m]: the one word I have most problems with in your sentence is "just"
10:28 Company: zamundaaa[m]: as I said in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/313#note_2424936 - just align the image
10:28 zamundaaa[m]: Dividing by a scale factor is really not more complicated than multiplying by one
10:28 Company: zamundaaa[m]: I'm sure the right padding or margin probably can do it?
10:29 kennylevinsen: well, do note that applying the x120 factor on the current proposal was messed up repeatedly, giving rounding errors
10:29 kennylevinsen: so even simple things can go wrong :P
10:29 zamundaaa[m]: Company: on the application side, you need new API if you want pixel perfect subsurface positioning
10:29 zamundaaa[m]: There is really no way around that
10:30 zamundaaa[m]: But yeah, adding padding is something the toolkit could do with current APIs to hide a lot of the sizing issues
10:34 Company: kennylevinsen: I should have made the scale factor in my new renderer a fraction probably
10:34 Company: but yes, carrying this stuff around without rounding errors is HARD
10:34 Company: and there's constantly dumb things going wrong
10:35 Company: like 0.4+0.4 < 0.8 but 0.8 > 0.8 with floating point
10:35 Company: or I should say 2/5 + 2/5 < 0.8 < 4/5
10:35 Company: (I think those are the right numbers)
10:56 wlb: wayland-protocols Merge request !314 opened by Simon Ser (emersion) governance: drop adoption website section https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/314
16:13 wlb: wayland/main: Simon Ser * build: bump to version 1.22.93 for the RC1 release https://gitlab.freedesktop.org/wayland/wayland/commit/0b1626f47346 meson.build
16:14 wlb: wayland New tag: 1.22.93 https://gitlab.freedesktop.org/wayland/wayland/tags/1.22.93
16:17 wlb: wayland.freedesktop.org/main: Simon Ser * releases: add wayland 1.22.93 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/e2016965773e releases.html
17:25 JoshuaAshton: It's nearly icon day everyone :D
17:25 JoshuaAshton: I'm so excited
17:54 swick[m]: emersion: can you please hold off merging until we have an official position in gnome?
17:54 emersion: GNOME has a few days to NACK if they want to
17:55 emersion: i will not hold off much longer, the 30 day period has elapsed
17:55 emersion: also, please understand the consequences of NACK'ing before doing so
17:55 swick[m]: various people are away right now enjoying a longer weekend
17:56 emersion: i think there was plenty of time already, sorry
17:56 swick[m]: the MR was opened 5 month ago
17:56 emersion: yes
17:56 swick[m]: you can wait another week
17:57 emersion: sgh
17:57 emersion: sigh*
17:57 JoshuaAshton: :/
17:57 emersion: definitely didn't have surprise NACK on my bingo card for this one
18:01 LaserEyess: swick[m]: as an individual wayland developer, not a gnome rep, do you have any reason to NACK it?
18:02 JoshuaAshton: I mean Gnome has had half a year to make an official position about the protocol that links a few wl_buffers to a xdg_toplevel at this point...
18:02 JoshuaAshton: It's getting a bit silly at this point
18:02 emersion: and it's not like i just said that i intend to merge out of the blue
18:03 emersion: activity has resumed a few weeks ago and ACKs have been accumulating
18:10 bl4ckb0ne: on which MR ?
18:11 emersion: xdg-toplevel-icon
18:11 JoshuaAshton: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
18:16 Company: that whole protocol is cute
18:17 Company: 500 comments and then that's the result
18:17 JoshuaAshton: We'll have bike storage for the whole of Europe by the time it's out.
18:18 JoshuaAshton: The new governmental plan to reduce fossil fuel pollution and increase air quality is simply more Wayland bikeshedding :D
18:18 Company: at least we finally get the icon-theme spec into it, now that we decided we likely want to get rid of it
18:19 emersion: can always extend with its replacement later
18:19 emersion: if any
18:19 swick[m]: and status updates via icons will come back! amazing!
18:19 swick[m]: there is never a good way to go from more features to less features
18:20 swick[m]: that's why the whole X11 to wayland transition is so painful
18:20 emersion: you are free to not implement it, and you are free to ignore the pxiel buffers
18:20 swick[m]: that's not how this works and you know it
18:20 Company: it's also great that the compositor tells you the size it wants but not the scale
18:20 Company: but you can then provide a scale with your buffer!
18:21 emersion: Company: the reason is explained
18:21 emersion: in the 500 comments
18:21 swick[m]: everything is explained. doesn't mean it makes sense.
18:21 Company: not a fractional one though, because fractional ones weren't the thing yet
18:22 Company: I don't care much about the protocol anyway
18:22 JoshuaAshton: If you have gripes with the xml, why not post your comments on the protocol instead of just making passive aggressive comments on #wayland?
18:22 Company: it's a cute playground to keep people busy though
18:22 JoshuaAshton: Wow, that's so fucking rude, wtf
18:23 swick[m]: but saying everyone is bikeshedding is not rude?
18:23 Company: You haven't heard me being fucking rude yet
18:23 swick[m]: and to answer the question why not earlier: because our concerns got ignored and everyone just moved on to more productive things
18:23 emersion: alright, let's stop here
18:23 swick[m]: it's hard to continue engaging when your concerns are not taken seriously
18:24 swick[m]: and this is not out of the blue either. we voiced our concerns early on.
18:24 Company: I don't think the whole process works, because if something ends up with 500 comments it's a mess
18:25 swick[m]: that's one way to handle critisism
18:26 emersion: that's one way to handle rude comments
18:26 swick[m]: no offense, but you're view here is very much clouded
18:27 emersion: just FYI, i was not the one to suggest a kick
18:27 swick[m]: then more than one people are really bad at handling criticism
18:27 emersion: now, let's just move on
18:28 swick[m]: easy to say when you have all the power to decide when the time is to move on
18:28 swick[m]: but sure
18:28 emersion: it is time to move on when discussions go out of hand
18:29 swick[m]: just keep in mind that this isn't how you build relationships
18:29 swick[m]: and only makes the situation worse
18:34 swick[m]: I'm honestly really sad to see that wayland has become a place where people try to force some protocols in, instead of trying to come up with a solution that works for everyone.
18:35 swick[m]: I'd rather not NACK anything, but when all concerns get ignored and there is no attempt made to understand each other and come up with a solution for everyone, then there isn't much else to do.
18:36 d_ed[m]: It shouldn't be a place where some people can deliberately stonewall forever either.
18:37 swick[m]: that you that some members are stonewalling things is really sad
18:37 swick[m]: *think
18:43 daniels: enough.
18:43 daniels: I’ll clear this tomorrow
19:19 daniels: there is so much in this that is so far out of line. the disrespect is incredible, and there is no way for anything productive to happen whilst people are just firing pot shots at others from (semi-)hidden grievances. I’ll clear +m in the European morning, but if there is anything close to a repeat of this then it will be a kick instead. be productive or don’t speak. thanks.
19:20 daniels: (the same applies to MR comments btw)