Alon Levy <alevy@xxxxxxxxxx> writes:
>> Good question.
>>
>> I don't know of a good way to deal with the situation where the new
>> client is unable to handle existing surfaces. I suppose in principle
>> spice-server could emulate their existence, sending them as images, but
>> I'm not familiar enough with spice-server to say whether that is
>> feasible.
>
> Sending a surface with a format the client doesn't recognize as an image
> - how does that help? you'd want to render anything dependent on that
> surface. And then the guest will be notified of the reduced
> capabilities and needs to never use those surfaces again (better yet,
> destroy them since they are just taking space).
>
> The rendering is already accomplished in on_new_display_channel_client
> with the red_flush_current(worker, 0) call, which recursively goes to
> all the dependent surfaces of each drawable and renders it too.
The scheme I had in mind was this:
- When a new non-a8-capable client appears, don't send it any of the
a8 surfaces
- If the client doesn't understand a8 surfaces,
- keep all a8 surfaces rendered on the server side
- if the guest sends a command using an a8 surface as a
destination, simply render the command on the server side
- if the client sends a command using an a8 surface as a source,
rewrite the image object to be a real image referring to the
server side bits (which are also sent or possibly cached)
rather than a surface
But it's much simpler to just say that the guest should stop referring
to a8 surfaces if the client can't handle them.
Ie., the same scheme as for commands: When a client disconnects,
spice-server changes the capability bits, then processes everything in
the ring. After this, the guest is expected to stop referring to a8
surfaces (and may indeed want to destroy them as you say).
Soren
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel