01:00 wlb: weston Issue #933 opened by Matthias Clasen (matthiasc) Output transform misleading description https://gitlab.freedesktop.org/wayland/weston/-/issues/933
06:22 karenthedorf: So I'm noticing that llvmpipe destroyes wl_buffers *before* wl_buffer.done() when I resize. I'm assuming this is "Not an error, but the results are undefined until a new buffer is attached and committed", right?
06:24 karenthedorf: This could be the reason why I see garbage (bad stride) during resize?
06:56 emersion: clients are allowed to destroy buffers early if they aren't going to re-use them
07:00 karenthedorf: Even if they are currently attached? Hmm, okay, thanks.
07:11 karenthedorf: Was just seeing "unknown event" in WAYLAND_DEBUG and assumed something bad was happening.
07:33 Company: I think it's because it's double-buffered state - until it's updated, the compositor will keep reusing whatever it has.
07:34 Company: which would mean what you're maybe not allowed to destroy is whatever backing store the buffer is using - but that depends on the buffer I suppose
07:34 Company: a solid color buffer has no backing store for example
08:13 wlb: weston Issue #933 closed \o/ (Output transform misleading description https://gitlab.freedesktop.org/wayland/weston/-/issues/933)
08:38 Company: so, I'm having fun with buffer transforms atm
08:39 Company: and I'm somewhat confused about what parts are before and after the transform now
08:39 kennylevinsen: “Fun”
08:39 Company: like, if i call buffer_damage() that needs to be buffer coords I assume and surface_damage() surface coords?
08:40 Company: I consider those things fun, because if they don't work I can turn them off and not worry
08:41 kennylevinsen: damage_buffer is in untransformed buffer coordinates yes
08:41 Company: but my 90/270 degree rotations don't work and I have no ide if that's mutter's fault or mine
08:43 kennylevinsen: Does the Weston transformed test client work? That one renders with buffer transforms but aim to always have the same final image orientation. Advances to the next one on a button press
08:45 Company: oh look, everything looks right if I have a square window
08:48 Company: do the test apps do fancy stuff like wp_viewporter and such?
08:49 Company: actually, is wp_viewport's source size buffer or surface coordinates?
08:50 Company: considering we leave it unset, that should mean the whole buffer - but we do set the destination
08:55 Company: nope, that's not it
08:59 Company: figured out it's indeed my fault
08:59 Company: used cairo to save the buffer before submitting and that one was wrong
09:00 YaLTeR[m]: if you aren't already, it's helpful to check on weston, and also the mutter paint damage thing
09:01 Company: does weston have a rotation flag? didn't find one in --help
09:03 Company: because the other struggle I have is trying to click stuff on a rotated monitor
09:03 Company: it's something that should not be that hard
09:03 Company: but my brain can't make my hand move the mouse properly
09:08 wlb: weston Issue #930 closed \o/ ([regression] weston doesn't update screen if it was deactivating when a dialog was fading out, and it has been reactivated https://gitlab.freedesktop.org/wayland/weston/-/issues/930)
09:08 wlb: weston Merge request !1570 merged \o/ (drm-backend: really reset/restart outputs of a failed commit https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1570)
09:08 wlb: weston/main: Michael Olbrich * drm-backend: really reset/restart outputs of a failed commit https://gitlab.freedesktop.org/wayland/weston/commit/1c7cf4796a38 libweston/ backend-drm/drm.c compositor.c
09:12 Company: fun fact: Cairo performance tanks with rotated buffers
09:13 Company: my benchmark goes from 60fps to 12fps just by rotating the screen
09:14 Company: not that I care about Cairo a lot, but useful to know
09:14 YaLTeR[m]: so everyone using gimp on a rotated 4k display is suffering?
09:14 YaLTeR[m]: and LO
09:19 Company: not for the next 10 years probably ;)
09:20 Company: and no, that's only when you draw to a rotated buffer
09:20 Company: and Gimp and LO don't do buffer transforms
09:20 Company: I suspect cairo has a bunch of optimization paths that don't trigger when the cairo context is rotated
09:20 Company: because Cairo doesn't track dihedral transforms
09:21 Company: but that's just my guess
09:23 Company: because I know it has this whole management of pixelgrid-aligned rectangles
09:25 Company: I'm trying the same thing with keeping clip infos alive throught the GTK stack so I can reduce solid color draws to glClear() and such
09:26 Company: and I made a few fundamental different design decisions early on that make that somewhat easier
09:27 Company: like, cairo_matrix_t is doubles, and rotate() does sin() and cos() and then you and up with M_PI and stuff
09:27 Company: and that accumulates rounding errors real quick
09:27 Company: and GTK uses GskTransform which tries to keep the steps alive that were taken to arrive at that matrix - and it deals in degrees, not radians
09:29 Company: (and then people use transform_new_from_matrix() for translations in their code, but that's a different story)
17:54 emersion: can i get an ACK from a developer on this? https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/402
18:17 emersion: thank you!
18:17 wlb: wayland/main: Simon Ser * scanner: extract validator function emission to helper function https://gitlab.freedesktop.org/wayland/wayland/commit/caaa308c0d40 src/scanner.c
18:17 wlb: wayland/main: Simon Ser * scanner: fix validator for bitfields https://gitlab.freedesktop.org/wayland/wayland/commit/c669d992599d src/scanner.c tests/data/example-server.h
18:17 wlb: wayland/main: Simon Ser * tests: add enum bitfield test https://gitlab.freedesktop.org/wayland/wayland/commit/fa1811ce3e14 tests/ data/small-client-core.h data/small-client.h data/small-server-core.h data/small-server.h data/small.xml enum-validator-test.c
18:17 wlb: wayland Merge request !402 merged \o/ (scanner: fix validator for bitfields https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/402)
18:19 ManMower: loving that. it never even occurred to me... thanks for fixing it. :)
22:31 karenthedorf: (Increadibly slow reply) Company: Well... llvmpipe seems to destroy the shm_pool eagarly the moment it's made a wl_buffer from it. Then destroyes the wl_buffer the moment it knows it's the wrong size. But that's probabally fine as long as the backing file isn't destroyed. Which shouldn't happen until both client and server close the fd.
22:41 kennylevinsen: karenthedorf: were you writing a compositor or a client?
22:43 karenthedorf: Client