ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
Calandracas_ has joined #wayland
guru_ has joined #wayland
KDDLB has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Calandracas has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
<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?
<karenthedorf>
This could be the reason why I see garbage (bad stride) during resize?
ShapeShifter499 has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
cyrinux has joined #wayland
Company has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
<emersion>
clients are allowed to destroy buffers early if they aren't going to re-use them
<karenthedorf>
Even if they are currently attached? Hmm, okay, thanks.
guru__ has joined #wayland
<karenthedorf>
Was just seeing "unknown event" in WAYLAND_DEBUG and assumed something bad was happening.
guru_ has quit [Ping timeout: 480 seconds]
<Company>
I think it's because it's double-buffered state - until it's updated, the compositor will keep reusing whatever it has.
<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
<Company>
a solid color buffer has no backing store for example
<Company>
so, I'm having fun with buffer transforms atm
<Company>
and I'm somewhat confused about what parts are before and after the transform now
<kennylevinsen>
“Fun”
<Company>
like, if i call buffer_damage() that needs to be buffer coords I assume and surface_damage() surface coords?
<Company>
I consider those things fun, because if they don't work I can turn them off and not worry
<kennylevinsen>
damage_buffer is in untransformed buffer coordinates yes
<Company>
but my 90/270 degree rotations don't work and I have no ide if that's mutter's fault or mine
<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
<Company>
oh look, everything looks right if I have a square window
<Company>
do the test apps do fancy stuff like wp_viewporter and such?
guru__ has joined #wayland
louis-g has joined #wayland
<Company>
actually, is wp_viewport's source size buffer or surface coordinates?
<Company>
considering we leave it unset, that should mean the whole buffer - but we do set the destination
guru_ has quit [Ping timeout: 480 seconds]
<Company>
nope, that's not it
gryffus has joined #wayland
<Company>
figured out it's indeed my fault
<Company>
used cairo to save the buffer before submitting and that one was wrong
YaLTeR[m] has joined #wayland
<YaLTeR[m]>
if you aren't already, it's helpful to check on weston, and also the mutter paint damage thing
<Company>
does weston have a rotation flag? didn't find one in --help
gryffus_ has quit [Ping timeout: 480 seconds]
<Company>
because the other struggle I have is trying to click stuff on a rotated monitor
<Company>
it's something that should not be that hard
<Company>
but my brain can't make my hand move the mouse properly
<Company>
fun fact: Cairo performance tanks with rotated buffers
<Company>
my benchmark goes from 60fps to 12fps just by rotating the screen
<Company>
not that I care about Cairo a lot, but useful to know
<YaLTeR[m]>
so everyone using gimp on a rotated 4k display is suffering?
<YaLTeR[m]>
and LO
<Company>
not for the next 10 years probably ;)
gryffus has quit [Read error: Connection reset by peer]
<Company>
and no, that's only when you draw to a rotated buffer
<Company>
and Gimp and LO don't do buffer transforms
<Company>
I suspect cairo has a bunch of optimization paths that don't trigger when the cairo context is rotated
<Company>
because Cairo doesn't track dihedral transforms
<Company>
but that's just my guess
gryffus has joined #wayland
<Company>
because I know it has this whole management of pixelgrid-aligned rectangles
guru_ has joined #wayland
<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
<Company>
and I made a few fundamental different design decisions early on that make that somewhat easier
<Company>
like, cairo_matrix_t is doubles, and rotate() does sin() and cos() and then you and up with M_PI and stuff
<Company>
and that accumulates rounding errors real quick
<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
<Company>
(and then people use transform_new_from_matrix() for translations in their code, but that's a different story)
<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.
<kennylevinsen>
karenthedorf: were you writing a compositor or a client?
<karenthedorf>
Client
tzafrir has quit [Read error: Connection reset by peer]