> > > ----- 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? No, we don't do that. We drop operations in the pipe if a new operation comes along - so basically we only drop operations if the network is slow. DFPS is in the X driver, not in the X sever. It can be done both in local and remote modes (I think that's a better distinction then with shared / without shared memory), with different collection (batching) times. > > From client side pov, gtk/gtk3 is syncing redrawing with a paint clock, > hopefully already. > > > Anyways as Christophe said, benchmarks would be good, those will hopefully > > also help to determine > > what is the best thing to do here. Benchmarks so far: video playback is slightly faster (3% +-1%). PerformanceTest 8.0 is worse - both in results and in cpu (taking remote-viewer and qemu together). My methodology is messy - looking at top while running the tests. For video playback it was fairly consistent, for PerformanceTest less so. > > > > Regards, > > > > Hans > > _______________________________________________ > > Spice-devel mailing list > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel