Hi, On 08/13/2013 08:33 PM, Alon Levy wrote:
The new protocol is an extension optionally supported by the client if setting this capability bit.It includes 4 new messages, 3 are new messages (SHM_OFFER, SHM_REPLY, SHM_DAMAGE) and one replaces an existing message (SURFACE_CREATE_SHM replaces SURFACE_CREATE), plus a capability bit that both server and client advertise (SPICE_DISPLAY_CAP_SHARED_MEMORY). If the server sees the client capability, it will send MSG_DISPLAY_SHM_OFFER right after the display channel handshake. client replies with MSGC_DISPLAY_SHM_REPLY - accepted = 0 - nothing changes, return to normal behavior - accepted = 1 - shared memory behavior commences as described below. In shared memory mode: 1. every message read from the qxl device (via the qxl interface interface_get_command) is: 1.1 immediately rendered into the framebuffer * since the framebuffer is a shared memory segment, the client can immediately use it.
So any drawing will cause rendering? IE the trouble some apps the codewaver guys were trying to deal with which draw things 1 pixel at a time will cause 1000-s of renders / second ? Not sure if this is a good idea, we should probably do some batching here, or simply render X times / second (skipping rendering when there is nothing to render). Anyways as Christophe said, benchmarks would be good, those will hopefully also help to determine what is the best thing to do here. Regards, Hans _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
