From Spice
There are a variety of issues in the current protocol that we'd like to change in a one-time backwards incompatible change to version 2.0 of the protocol. Since we only want to do this once its important to not forget any change when we do this break. This page tries to list all the things we would like to change:
Remove clip-by-path in all drawing operation
This is quite complex to implement in clients, and it is not fully specified (i.e. what exact bezier precision and what fill mode) which is bad if the server and the client rasterizes to different pixels and thus clip differently.
The current win32 driver can emit these, but in practice it never seems to happen.
Replace DrawStroke with a simpler linedrawing operation
Path stroking is a very complex operation that is a pain to implement in clients. It also has a lot of subtleties in the specification meaning that two different implementations can touch different pixels. Also, wide lines are very uncommon in actual use. So, its better to have e.g GDI simplify the strokes to another primitive so that we're sure we get the same pixels drawn as GDI expects in both client and server.
Instead we want a traditional one-pixel wide solid line drawing operation, fullfilling the win32 GDI rasterization rules.
The current win32 driver only uses DrawStroke for thin (1-pixel) lines, but does send bezier curves.
Add Offscreen surface targets
We want to support rendering to multiple surfaces, this means we need to change each drawing operation, adding a destination surface argument.
Send SPICE_ADDRESS as 32bit on the network
Its currently 64bit which is unnecessarily inefficient. However, this means we need to fully disconnect the structures used for network protocol use and the in-memory structures. This is generally a good idea though, as it makes us more flexible wrt protocol extensions.
Simplify SpiceROPDescriptor
This enum is currently 10 bits, describing just a ROP2 operation, which is only 4 bits. So, multiple inputs really mean the same thing. We should just send a normal ROP2 value instead.
Remove vector glyph support in DrawText
This is currently not used an unnecessarily complex.
Simplify DrawText ROPs
Currently DrawText supports two rops, one for foreground and one for background. This is problematic because the glyphs can be specified as 4bit alpha to be composited with OVER, and composition and raster ops are inherently incompatible. Furthermore, win32 seems to not ever use fore_mode and only solid or noop for back_mode.
So, what we want is two modes, either blend the fg brush on the destination using alpha from the mask, or blend the fg brush on the bg brush using the alpha and relace the destination with this. Don't allow generic rops for text.
Also, we probably want a more efficient text rendering protocol that does not send a rasterized glyph each time it is used.
Upgrade CELT to latest version
There has been a new celt release. The library is incompatible, but I don't know if there are any stream version changes. If there are we should ensure we bump the requirements to the latest celt version.
Possible changes in audio streaming protocol
Monty had some changes he wanted to do to avoid hissing when audio streams were changed. Need to talk to him about the details.
Make some parts of drawing operations optional
We want to add a flag to SpiceMsgDisplayBase where optional parts can be set. This way we don't have to send clip and mask for each operation if they are not used.
Protocol Version field (minor & major) should be 1 byte sized each
Like other protocols (SSL, for example). 4 bytes each is a waste of bandwidth.
Authentication should move to SASL
Much more flexible and already available in QEMU
remove sub-list messages
It's rarely used (if any) and consumes (when not used, 99.9% of the time) 4 bytes per each message
Void messages do not need size
Some messages which are void (REDC_ACK, RED_DISPLAY_MARK, for example), do not need anything but message ID and type - 10 bytes at most. Right now, 18 bytes are sent (inc. message size = 0 and sub-list message size - see above section).
QUIC version number should be changed from 0.0
QUIC and GLZ_RGB version numbers should use 1 byte per number
Similar to the overall Spice protocol version size (4 bytes each), QUIC and GLZ_RGB use 2 bytes per number. 1 per number is enough.
QUIC header and Image Descriptor contain some redundant data
For example, width and height of the image is expressed in both. Waste of 8 bytes (actually more, as RedDrawBase before that already contains that information as well)
Create messages with multiple data in it (DISPLAY_DRAW_BLACKNESS, for example)
I can see in many cases where you have a batch of messages, all the same type, with different data within. For example. DISPLAY_DRAW_BLACKNESS with different RedDrawBase (and mask is ignored). Should be able to do something like DISPLAY_DRAW_BLACKNESS_MANY and have an array of RedDrawBase in a single message (tiles if you compare to VNC).
Optionally, split big messages (such as DISPLAY_DRAW_COPY) to several messsages
I have a 805,158 bytes DISPLAY_DRAW_COPY message (containing a QUIC image within). Over LAN, it takes >500 packets to desegment to a single message. On WAN, this is a bit too much. Over WAN, we need to use smaller tiles. Note: it may be just the first image.
RED_PING should not send 250K of zero'ed data to test bandwidth
If there is any compression on the route (VPN, for example), it will completely distort the results.
Change rgb_to_yuv420() functions to use MMX/SSE2 based functions
Should provide 2-10x performance improvement.
Smartcard improvements
Currently, the message format is too closely tied to libcacard internals. There should be a different message per smartcard operation (reader plug/unplug, smartcard insertion/removal). And we need a way to associate a message from the client with the answer from the server (eg to map "reader added" answers which contain a reader id assigned by QEMU with the originating message and internal reader data structure), currently we wait for a message answer before sending the next one.
