----- Mensaje original ----- > 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). Isn't that what we are already doing? So shouldn't it be addressed separately?