[Spice-devel] [RFC 2/2] add shared memory display channel support

Marc-André Lureau mlureau at redhat.com
Wed Aug 14 06:28:19 PDT 2013



----- 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?

>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.
> 
> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 


More information about the Spice-devel mailing list