ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
feaneron has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
FreeFull has quit [Quit: Lost terminal]
paulk-bis has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
paulk has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
sally has quit [Quit: sally]
sally has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
glennk has joined #wayland
crissdell has quit [Read error: Connection reset by peer]
crissdell has joined #wayland
FreeFull has joined #wayland
soreau has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
soreau has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<pq>
soreau, you need the simple-shm buffer logic. There is no guarantee that the compositor releases the shm buffer you posted until you have committed another update to the same surface. Even then it's not a (timely) guarantee, so you might need even a third buffer sometimes.
<soreau>
pq: but that's not what vyivel indicated :P
<pq>
soreau, particularly Weston with Pixman-renderer won't give you an early release.
<soreau>
and that's what I was thinking when reading through simple-shm.c
<pq>
soreau, re-using wl_buffers is highly desirable and intended. Destroying and creating shm buffers has a potentially significant cost.
<vyivel>
you can reuse buffer on release
<vyivel>
if it's not released you can't reuse it
<soreau>
ah
<soreau>
I'm only updating max 1fps so far, so I guess it's not a problem
<pq>
therefore you usually have a pool of buffers that starts with one buffer, adds new buffers as needed, and keeps track of which ones are free to be re-used.
<pq>
fps is irrelevant
<pq>
Weston with Pixman-renderer will keep your shm buffer in use, until you post another one or destroy/unmap the surface. No matter how many hours you take.
<soreau>
when you create the pool, does the size need to be twice as large to accommodate for two buffers?
<pq>
I mean the concept of a pool, not a literal wl_shm_pool. But of course you could implement it with a large wl_shm_pool.
<soreau>
pq: ok, thanks for the input
<soreau>
so far, it just reuses the wl_buffer without regard to release events, and it seems to work ok FTM
<pq>
yeah, that's luck
<soreau>
well if the server is running at a 'normal' rate and the client is reusing at 1fps, I think it releases by then anyway.. but yea, could be a race
<soreau>
which is why I asked the question in the first place
<pq>
If your compositor is GPU-accelerated, it probably copies the shm buffer contents into its own copy very soon, and your next frame modifications do not get read too early.
narodnik2 has quit []
<soreau>
but I just got wayfire working headless on a lowly box, so we'll see
<pq>
well, Weston with Pixman-renderer won't release, and that's what the protocol allows.
<soreau>
I was thinking of dumbing down the headless refresh rate, but maybe 15fps is too dumb
<soreau>
pq: I see
<pq>
if you have a compositor with a non-GL non-Vulkan software renderer, there is a good chance it won't release until post another buffer
<soreau>
hm
<zamundaaa[m]>
KWin doesn't release the shm buffers with the OpenGL renderer either
<zamundaaa[m]>
It always keeps the last buffer on the surface
<soreau>
but if you reuse the buffer before release.. what happens?
<soreau>
UB?
<pq>
unknown
<pq>
the compositor might be reading the buffer while you are writing to it, meaning the compositor gets garbage or inconsistent pixels
<soreau>
well I want this client to be an example widget and example pywayland client (for myself and others) so I will likely 'fix' it to simple-shm specs
<pq>
cool
<soreau>
pq: yea that's the whole point of implementing the epoll custom loop
<soreau>
because I don't want to potentially read/write to variables when updating weather stuff, for example
<soreau>
so instead I use eventfd write/reads
<pq>
oh, yeah, avoiding races in general, good
<soreau>
yes
<soreau>
even when handling sigint, I write to a 'close_fd' and handle it in the event loop
<soreau>
because threads are sticky in python, and I need ^C to work
<soreau>
and ofc, do the same thing on xdg close event
dwt has joined #wayland
narodnik has quit [Quit: WeeChat 4.5.1]
Moprius has joined #wayland
rasterman has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
kts has joined #wayland
kts has quit [Quit: Leaving]
yppy has joined #wayland
<yppy>
the pointer-constraints and relative-pointer protocols seem to be 10 years old, widely used, and implemented in every desktop compositor, is there a reason they are marked as unstable instead of staging?