03:07 DemiMarie: There is one case I know of where I have read that X11 is legitimately better than Wayland, and that is e-book readers using e-ink displays.
03:22 soreau: what is all this 'reading' as opposed to 'measuring'?
03:22 soreau: anyone can write something for someone else to read but provable measurements are much more telling
03:26 DemiMarie: soreau: the embedded hardware in question (Amazon Kindle) is locked down
03:26 soreau: how does this make any difference?
03:27 DemiMarie: I also don’t remember the post in question
03:27 DemiMarie: in other words: this is hearsay, which is why I made a deliberately weak claim
03:28 DemiMarie: I believe the reasoning was that the expose model lends itself very easily to partial repaints, as opposed to having to do delta calculation in software.
03:29 soreau: It's like a nanosecond race to see who can link input to output the fastest - and there's nothing that is provable without hardware instruments designed for such measuring
03:30 soreau: the winner might as well be printf :P
03:30 ezzieyguywuf: so xdg_toplevel::close is a request sent by the server? what if I want to close the window on the client size, do I send a particular event or request or do I just destroy smthn?
03:31 soreau: ezzieyguywuf: you can exit(0) in any flavor you'd like
03:32 soreau: most decent compositors are prepared to handle client crashes even
03:32 ezzieyguywuf: hah true true - curious though, what if I just want to close the wayland window but still keep the program running
03:32 soreau: close event just means 'you might want to exit gracefully because we aint gonna give you much more attention from this point on'
03:33 ezzieyguywuf: also, my compositor doesn't have server-side decorations, so in this case, how do I e.g. add a title bar and close/minimize/maximize buttons, do I have to like draw these things in gimp and load them in somehow, or is there a more elegant way to do this?
03:33 soreau: but there is documentation like https://wayland.app/protocols/xdg-shell#xdg_toplevel:event:close
03:33 ezzieyguywuf: soreau: but for example, let's say I add a close button, how do I tie that to the close event?
03:33 ezzieyguywuf: soreau: yea I was reading that, but it was unclear to me what triggers the event
03:35 soreau: ezzieyguywuf: if you're close button is rendered by the compositor (i.e. SSD) then you'd tie that to a close event. If you're the client doing SSD, the close button does whatever you want it to, typically exit gracefully, the same as what you'd do when getting a close event
03:35 soreau: your*
03:36 ezzieyguywuf: hm I see
03:36 soreau: ezzieyguywuf: to do compositor decorations i.e. SSD, you have to figure out what works best from compositor POV
03:37 soreau: if you want to do it with GL, cairo, compute, whatever..
03:37 soreau: it's all up to you
03:37 soreau: for CSD, it's up to the client
03:37 soreau: very conflicted and confusing, but such is the protocol API designed
03:38 ezzieyguywuf: I see. thank you for the help
03:38 soreau: np
03:40 soreau: ezzieyguywuf: if you want to 'close' the window but keep the program running, you might want your compositor to simply not render the window
03:40 soreau: like an unmap of sorts
03:53 danieldg: note the 'close' event is also sent by the compositor if the user hits alt-f4 or similar "close" key combinations, regardless of ssd/csd
04:03 ezzieyguywuf: 👍 yes I'm already handling theh 'close' event gracefully, moreso I was wanting to emit the event myself
04:03 ezzieyguywuf: but I see now that I don't rly need to do that
04:04 ezzieyguywuf: wrt decorations I think server-side decorations are really ideal, since I expect they will provide the most "native" experience, however in the absense of server support I guess I'll have to draw my own. they'll be pretty ugly though lol
04:07 danieldg: yep, gnome expects everyone to use gtk (therefore getting native looking csd)
04:08 soreau:uses pixdecor
04:10 soreau: ezzieyguywuf: since it sounds like you're writing a client, you might look into libdecor
04:14 DemiMarie: danieldg: yup, which is why I consider Wayland not requiring SSD (and thus requiring CSD) to be a mistake
04:14 soreau: it is
04:15 soreau: but it was the easiest thing to get going in the beginning
04:15 DemiMarie: during early Weston development?
04:15 danieldg: it also works better for apps like chrome that want to put tab bars in the title bar
04:16 danieldg: but yeah, I mostly agree with you
04:17 DemiMarie: I think Mutter is the only major desktop compositor that doesn’t support xdg-decoration
04:20 soreau: what makes it major? let's be real here - people are largely disappointed with the show and moving on to bigger and better things
04:20 danieldg: major as in a significant number of people use it
04:21 soreau: metrics?
04:21 danieldg: I think it's default in rhel9, maybe 8 too?
04:22 danieldg: no I don't have metrics, and I don't want them
04:23 soreau: defaults are meant to be changed, especially when it comes to linux :P
04:24 danieldg: it's amazing how lazy some people are
04:24 soreau: maybe users == those that are forced to use it by some corporation
04:24 danieldg: and that too
04:24 DemiMarie: I think it is the only supported Wayland compositor in RHEL8+, and the only supported KMS application in RHEL10.
04:24 DemiMarie: There are definitely people who choose to use GNOME of their own free will, and who strongly prefer GNOME to other desktop environments.
04:24 soreau: because none of the other users that actually make up the base, matter
04:25 danieldg: yes, I know some of those people
04:27 soreau: DemiMarie: probably the same group that complains incessantly about the very platform they chose :P
04:28 DemiMarie: soreau: I’m not so sure. I don’t think I know anyone who would say GNOME is _perfect_, but I wouldn’t say that the GNOME fans I know constantly complain about it.
04:39 DemiMarie: GNOME really does have a place, and there are people for whom it is the best option. It’s what I would recommend to someone who wanted desktop Linux for their child’s first computer.
08:04 Ermine:have met a genuine gnome fan
08:34 colinmarc: if I want to write a test vulkan app that displays the difference between swap and the presentation time, I have to bypass the wsi, right? because the present time extension hasn't shipped
09:11 daniels: colinmarc: correct :\
09:17 daniels: soreau: also even if I didn’t happily use GNOME, you know better than to start desktop wars here
09:46 soreau: daniels: is that kinda like Star Wars?
09:47 soreau:has never heard of 'desktop wars' before
09:49 soreau: I guess you have to pick Light or Dark side - and this all depends.. on your theme!
09:57 soreau: In the end, everyone falls for Wayfire, the Princess Leia of the parody 👍
09:58 soreau: and don't forget the Star Wars xscreensaver, because how would we have moved forward (or backward) without it ;)
10:06 colinmarc: Ok, so I figured out that I can just create a second feedback object on my surface even when using WSI, that makes reading the presentation time easier. However, I'm stuck trying to get the frame callback timing. Mesa doesn't even use the frame callback if wp_presentation is available: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_common_wayland.c#L2524-2533
10:06 colinmarc: That makes me wonder if I'd even be simulating a "real" app with my test app. Or if timing the frame callback even reduces latency for fullscreen games. I feel like I'm missing something here about how this frame scheduling thing is supposed to work
10:13 colinmarc: Basically my question is: how can I control when MAILBOX apps render, especially if they're limiting themselves to a certain framerate?
11:01 colinmarc:uploaded an image: (91KiB) < https://matrix.org/oftc/media/v1/media/download/AUDREbQSXS-WBgEqUbtda6YG2of8KtKG6sB0558g_EMSXrSYC-1M_M_7s8ozKsFvwZNgl9y48hsh6ArIu9ztjB9CeVVoTzFQAG1hdHJpeC5vcmcvTkFIZm1vd0hOamhGS0VSUEtaamNHYml0 >
11:01 colinmarc: cool to at least visualize the problem :)
11:05 daniels: colinmarc: when you say ‘control’ - what’s the context? are you trying to modify app behaviour from within a compositor, toolkit, plugin lib, other?
11:15 colinmarc: <daniels> "Colin Marc: when you say ‘..." <- sorry - context is I'm the compositor, and I want to do frame scheduling to reduce input lag
11:15 daniels: ah, right, I see
11:16 daniels: the best thing you can do is implement fifo and commit-timing
11:16 colinmarc: why fifo? I think my client here is using mailbox
11:17 daniels: that will actually increase latency for some clients, but can make it better for smarter ones
11:17 colinmarc: most of my clients are games running via xwayland, if that helps
11:18 colinmarc: I've seen examples online of delaying the frame callback based on an estimation of the client's frame time, is that not a recommended strategy anymore?
11:29 ifreund: its a good strategy if the client uses frame callbacks
11:30 ifreund: xwayland games dont though in general
11:35 colinmarc: what's the right strategy for xwayland games?
11:35 colinmarc: or is there none?
11:41 ifreund: colinmarc: afaik, the fifo protocol is the best approach
11:41 colinmarc: @ifreund it's on my list to implement anyway - do you mind explaining why it helps in this case though?
11:42 colinmarc: like I was under the impression that these games are using mailbox under the hood (unless I uncheck vsync)
12:10 colinmarc:uploaded an image: (56KiB) < https://matrix.org/oftc/media/v1/media/download/Ac3wK-6kb10cZk__gwyTC5Y-7183FC-SPQ6yjeqjkm8pW_uX_ohhPNkqUy-fJdvwLjb4JkE-0D_jWy_ossfmYrhCeVVsQkIAAG1hdHJpeC5vcmcvV2NTWW5OblpSYXlYT1JaVGhUS2VNc1JO >
12:11 colinmarc: here's the same game with an artificial 10ms delay in sending frame callbacks. it seems to work empirically at least
12:11 colinmarc: that 6ms is the input lag between commit and present
12:12 colinmarc: I have an nvidia system, let me try there with a different WSI stack
12:33 llyyr: colinmarc: all the games running through wine for me are using fifo, not mailbox
12:33 llyyr: regardless of vsync setting in individual games
12:42 colinmarc: <llyyr> "Colin Marc: all the games..." <- hm okay. how are you checking that?
12:42 llyyr: mangohud's present_mode config
12:44 llyyr: it should be reliable (works correctly with vkcube present_mode)
12:52 llyyr: Maybe the overlay layer in mesa should provide this info too, it seems mangohud is guessing