Open ascent12 opened 5 years ago
This seems fairly complicated. I'm not sure it's worth it.
This seems fairly complicated. I'm not sure it's worth it.
That's certainly a possibility. I'm currently writing a more complete proof-of-concept to see if it'll work as nicely in practice as I hope it will. If it turns out to be overly complicated or unwieldy, I'll just throw it out.
Note, the current solution for surface state add-ons is the commit sequence number.
The viewporter case is a little annoying because the viewport changes the buffer size. This matters because helpers like wlr_surface_at
rely on the surface size. I still don't know how to handle this, I can't think of anything else than adding a viewport field to the surface state directly. The viewport implementation would still separated from the surface implementation of course, but would populate the surface viewport field.
Another solution would be to add some way for external interfaces to mutate the surface state before commit, but it starts getting complicated (in which order should external interfaces mutate the state? etc).
Right now, if an extension protocol wants to have any state tied to a particular wl_surface commit, it's basically forced to implement its own tracking of different commits, or forces the burden onto the user, and there is often no value in making them do it.
Instead, I think it'd be worth creating a more general system for this, where extension protocols (and even non-protocols) can add their own state directly to a wlr_surface and can be managed properly over multiple commits. One thing in particular I think we need in the future (for explicit sync) is tracking of more than just a current + pending commit, and I think that this would make this easier.
It will allow us to easily take "snapshots" of the entirety of a client's state, instead of just their buffer. This is somewhat important for things like
wp_viewporter
and other extensions that affect rendering state.Examples
Here are some examples of what I think the usage would look like. I've skipped over some of the details, but it should gets the point across.
Other notes
wlr_renderer
could use this, and addwlr_surface_state_get_texture
.wlr_commit
.wlr_surface_state
is kind of a long name.wp_linux_explicit_synchronization
will work with this, but I haven't fully thought of the details. It would revolve around "locking" a state so that it won't be returned bywlr_surface_get_state
.wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1546