ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
mnadrian has joined #wayland
slim has joined #wayland
nadrian has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ManMower has quit [Read error: Connection reset by peer]
<pq>
emersion, on a quick look the docs look fine again, thanks!
dcz_ has quit [Ping timeout: 480 seconds]
<emersion>
cool!
fmuellner has joined #wayland
mvlad has joined #wayland
devilhorns has joined #wayland
flacks has quit [Quit: Quitter]
<zzag>
when should the compositor apply wl_subsurface::destroy() requests?
Azem has joined #wayland
<zzag>
when it's called or when committed?
<zzag>
when the surface is commited*
flacks has joined #wayland
<pq>
zzag, destroys are always immediate, I believe.
<pq>
zzag, wl_subsurface.destroy is exceptionally clear: "The wl_surface is unmapped immediately."
<zzag>
oh, right. cool nothing to fix in the compositor then :)
<pq>
The compositor animating the disappearance of a sub-surface makes no sense. :-)
<pq>
So if a client wants to play fine, it should unmap the top-level with all sub-surfaces intact. But this has a peculiar problem now thinking about it.
<emersion>
so the only way to let the compositor fade out a subsurface tree is to leak it?
<emersion>
ah, right, unmap toplevel
<pq>
yeah, basically
<pq>
we'd have to say that the compositor saves a snapshot of the whole sub-surface tree when it unmaps the root surface of that tree.
<pq>
so that when the client next destroys all sub-surfaces etc., the closing animation is not broken
<emersion>
yup, that makes sense
<pq>
annoying.
<pq>
also, "fade out a sub-surface tree" is even more fun, if you think about the visuals
<emersion>
yes
<emersion>
the only way is to render to an intermediate buffer the whole tree
<pq>
you have to flatten the whole sub-surface tree into a single image before any kind of fade effect looks right
<pq>
that's might actually give compositors a nice way to implement the unmapping - instead of a snapshot of sub-surface tree state, flatten the image.
<pq>
keep the flattened image and animate with that, not using any client buffers anymore
<pq>
if that was applied to unmapping wl_shm-backend surfaces too, we'd get wl_shm closing animations on the side
<pq>
*wl_shm-backed
<pq>
oh, well, that's not actually necessary
<pq>
only the flattening is
<pq>
oh hey, what happens, if you unmap a surface by destroying its role object, but then keep on posting new frames to the wl_surface? :-p
<pq>
talking about top-levels and such, not sub-surfaces which won't closing-animate
<zzag>
emersion: you could just destroy the parent surface and its subsurfaces will be unmapped
<zzag>
smells a bit "hacky"
<zzag>
but there perhaps no other better option?
<zzag>
there's*
<zzag>
regardless the compositor needs to know when it should freeze scene graph nodes associated with the window
Company has joined #wayland
<zzag>
as is, the compositor gets destroy requests in the following order
<zzag>
which can't be handled properly so the close animation looks correct
<pq>
I agree
<pq>
Whenever a surface where closing animations apply is unmapped, that is the instant to freeze the scenegraph contents for that surface and its sub-surfaces.
<pq>
Sub-surfaces never have closing animations themselves in a compositor.
<pq>
I presume we don't want to keep the window alive (taking content updates) while it is animating its unmap?
lxsameer3 has quit [Ping timeout: 480 seconds]
lxsameer3 has joined #wayland
Azem has quit []
lxsameer3 has quit [Ping timeout: 480 seconds]
Azem has joined #wayland
jgrulich has quit [Remote host closed the connection]
dblsaiko has quit [Remote host closed the connection]
dblsaiko has joined #wayland
Moprius has joined #wayland
cvmn has joined #wayland
jgrulich has quit [Remote host closed the connection]
dcz_ has joined #wayland
ppascher has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
lxsameer3 has joined #wayland
<MrCooper>
pq: sub-surfaces getting destroyed "immediately" is kind of ambiguous though, e.g.: 1) new buffer attached to parent surface and committed 2) sub-surface destroyed, parent surface becomes visible; however, the buffer attached in 1) is not ready for the compositor's next output frame yet. What should be displayed in the newly visible parent surface area?
<daniels>
the new buffer
ppascher has joined #wayland
<MrCooper>
that means the compositor cannot show a new output frame until that buffer becomes ready
<daniels>
not really, no
<daniels>
it only means that you can't break the coherence of subsurface trees
<daniels>
the easy option is to always take the current state and maybe eat a stall if something's ready
<MrCooper>
if you mean the sub-surface should remain visible in the next output frame, that's not really "immediate" then?
<daniels>
shrug
<daniels>
if you fade out a surface on wl_surface_destroy(), that's not immediate either
<daniels>
if you don't display the surface content in the next frame, that's also 'not immediate'
<daniels>
what matters is that the subsurface tree is coherent wrt the state the user asked to set
<daniels>
you don't get to arbitrarily mix and match
<MrCooper>
that sounds more or less like my thinking as well, I just wouldn't call that "immediately" :)
<daniels>
if you want to defer updates, then you get to either defer the entire tree's updates, or selectively cherry-pick the ones which are desync
<daniels>
it's 'immediate' in opposition to being latched on surface commit / parent sync mode
<MrCooper>
which depends on any previous (implicit) transaction involving that (sub-)surface
<daniels>
yeah, that seems reasonable
<MrCooper>
cool, thanks
fmuellner has quit [Ping timeout: 480 seconds]
neonking has quit [Remote host closed the connection]
duxsco has quit [Quit: Leaving]
neonking has joined #wayland
Azem has joined #wayland
PuercoPop has joined #wayland
maxzor has joined #wayland
<MrCooper>
robertmader[m]: I think emersion's point was that there's no generic way to find out if a buffer with a given modifier could be scanned out, other than trying to scan it out or at least creating a KMS FB for it on the target scanout device
<kennylevinsen>
how nice the world would be if gpu's could just tell us what to expect of them instead of having to go "can you do this? no? what about this? or this? or that? or this-oh that last one worked thanks"
<emersion>
something something buffer constraints
<kennylevinsen>
what happened to that btw?
fmuellner_ has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
duxsco has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
devilhorns has quit []
hergertme has quit [Remote host closed the connection]
hergertme has joined #wayland
c7s has joined #wayland
tzimmermann has quit [Quit: Leaving]
heeen[m] has joined #wayland
jmdaemon has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
Telvana has quit [Read error: Connection reset by peer]
Telvana has joined #wayland
agd5f_ has quit []
agd5f has joined #wayland
maxzor has joined #wayland
<zubzub>
22:37 < jadahl> zubzub: mutter has both directions implemented, maybe it can provide some inspiration
<zubzub>
thanks!
<zubzub>
will do
<zubzub>
meanwhile I got remote wayland->html5(browser)->native app c/p working \o/