ext_image_copy_capture_session_v1 format constraint changes are poorly defined

The protocol does not say what the contents of a ext_image_copy_capture_session_v1.done sequence are. Does the compositor have to send all constraints whenever any constraints change? If not, how does the client distinguish between only the size changing and no longer any formats being available? Sending the dmabuf formats every time is not reasonable due to the large amount of data.

Currently I see no reasonable way to handle this except by stopping sessions whenever any format constraints change.

added time estimate of

changed title from Changing ext_image_copy_capture_session_v1 format constraints is poorly defined to Changing ext_image_copy_capture_session_v1 format constraint changes are poorly defined

The expectation is to resend everything each time.

That doesn't make sense to me for toplevel sources which might get resized often.

What kind of issue are you hitting in practice with this approach?

The issue is one of efficiency. In the case of dmabuf-feedback, sending modifiers via arrays was considered expensive enough that a different mechanism was designed. But if you have to send all modifiers every time a captured window is resized, then surely that is much more inefficient than the dmabuf-feedback case where constraint changes are rare.

AIUI sway only sends a single format, at least the restrictions around 10-bit output formats seem to indicate this. But I support and send all formats supported by my renderer so the overhead would be many times higher than in sway.

All dmabuf_format messages combined take 1728 bytes on the wire on my system.

changed title from Changing ext_image_copy_capture_session_v1 format constraint changes are poorly defined to ext_image_copy_capture_session_v1 format constraint changes are poorly defined

The protocol states:

The compositor may re-send buffer constraint events whenever they change.

and

To advertise buffer constraints, the compositor must send in no particular order: [...]

That sounds pretty clearly defined to me.

You're right, reading the protocol strictly makes it clear. However, for the reasons mentioned above, I didn't realize that this could be the intention.

I'll do the following in my initial release of this protocol:

• Send the format constraints only during the initial burst.
• Stop sessions if the format constraints change.
• Send only size constraints on resize events.

All clients that I've looked at should work with this; they don't make use of the transactional nature of the "done" event anyway.

Ideally a new protocol version would allow me to solve this more correctly. For example, using a file descriptor to sends formats similar to dmabuf-feedback and having an event that tells the client that the format constraints have been reset.

This is incorrect per the spec.

I agree and I'm not saying this to bully anyone into changing the spec by creating facts on the ground. But

• applications exist first and foremost to serve their users and
• the toplevel-resize usecase is important to me

and I don't believe anyone will be served by me sending the same 2kb blob every time the user moves his mouse while resizing a window.

(And in any case I'm already violating the spec as described in #222 since that part of it breaks toplevel-resize completely and there is not even a spec-compliant workaround for it as far as I know.)

And I fully admit that it was my mistake to not realize that formats would have to be re-sent this often. I intuitively assumed that constraints would only even send a delta instead of the whole thing.