15:43 <wlb> wayland Issue #245 opened by () Proposal: require destructor events to be annotated https://gitlab.freedesktop.org/wayland/wayland/-/issues/245

16:03 <wlb> wayland Merge request !184 opened by () Reject identifiers reserved in C++ https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/184

16:46 <DemiMarieObenour[m]> How does XWayland handle double buffering?

16:59 <DemiMarieObenour[m]> Also, how does Wayland in general handle server-initiated resizes? Is there a way to do so without any glitches?

17:08 <kennylevinsen> It is handled by informing the client that a new size has been requested through a configure event.

17:10 <kennylevinsen> It is glitch free in that nothing happens until the client submits a new buffet with content in the new size

17:10 <kennylevinsen> (the window size is always the size of the last submitted buffer)

17:12 <DemiMarieObenour[m]> What happens to the pointer during that time?

17:20 <kennylevinsen> Whatever the user does with it and whatever the application sets the cursor buffer to. If the application is too slow to render, it'll lack behind during resize.

17:23 <DemiMarieObenour[m]> Gotcha

21:10 <DemiMarieObenour[m]> Is it a protocol error for a client to damage a surface and then commit without having submitted a new buffer, if the old buffer has not been released yet?

21:27 <kennylevinsen> DemiMarieObenour[m]: it's a no-op, as damage applies to the pending buffer of which there would be none.

23:30 <DemiMarieObenour[m]> kennylevinsen: what about attaching a buffer that is still in use?

23:53 <kennylevinsen> DemiMarieObenour[m]: that would be pointless as you are not allowed to mutate a buffer before it has been released, but I believe the wl_surface::attach comment about attaching a single buffer to multiple surfaces applies about weirdness.

23:54 <kennylevinsen> (Mutating a buffer when you are not allowed to generally leads to the application glitching as damage regions are incorrect.)