| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Also in new protocol don't send style data if not needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Internally and in the network protocol (for the new version) we
now store the actual number of segments rather than the size of the
full segments array in bytes. This change consists of multiple changes
to handle this:
* Make the qxl parser calculate num_segments
* Make the canvas stroke code handle the new SpicePath layout.
* Fix up is_equal_path in red_worker.c for the new layout
* replace multiple calls to spice_marshall_PathSegment with a single
spice_marshall_Path call
* Make the byte_size() array size handling do the conversion from
network size to number of elements when marshalling/demarshalling.
* Update the current spice protocol to send the segment count rather than
the size
* Update the old spice protocol to use the new byte_size functionallity
to calculate the size sent and the number of elements recieved
|
|
|
|
|
|
|
| |
With this function you can update an added uint32 after it being added.
To make this possible all the spice_marshaller_add_add_foo functions
now return a pointer that can be used as a reference when later
setting a value.
|
|
|
|
|
|
|
|
|
|
|
|
| |
red_parse_qxl.c starts to follow QXLPHYSICAL references and build up
data structures. Can zap a bunch of get_virt calls in red_worker.c,
followed by cleanups.
(de-) marshaller needs updates to deal with that. Also I suspect with
the get_virt() calls being gone we can offload more work to generated
marshaller code.
client doesn't build.
|
|
|
|
| |
Also adapt to tyops fix (s/rop_decriptor/rop_descriptor/).
|
|
|
|
| |
Also adapt to tyops fix (s/rop_decriptor/rop_descriptor/).
|
|
|
|
| |
Also adapt to tyops fix (s/rop_decriptor/rop_descriptor/).
|
|
|
|
| |
This is not supported currently anyway and was not generated before.
|
| |
|
|
|
|
|
| |
The RGB channels are compressed using JPEG.
The alpha channel is compressed using LZ.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Right now we always assume pointers are stored as SPICE_ADDRESS,
i.e. 64bit, independent on the size sent on the network.
This is required for 64bit architectures of course, but slightly overkill
on 32bit architectures, so needs fixing when all SPICE_ADDRESS elements
can be made internal.
|
| |
|
|
|
|
|
|
|
| |
We move all message structs from spice-protocol to spice as
we want to be able to change these as needed internally. The
on-network format is no longer defined by these structures anyway,
but rather by the spice protocol description.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a message has been read from the network we now pass it into
the generated demarshaller for the channel. The demarshaller converts
the network data to in-memory structures that is passed on to the
spice internals.
Additionally it also:
* Converts endianness
* Validates sizes of message and any pointers in it
* Localizes offsets (converts them to pointers)
* Checks for zero offsets in messages where they are not supported
Some of this was previously done using custom code in the client, this
is now removed.
|
| |
|
| |
|
|
|
|
|
|
| |
1) add an option to determine if a bitmap can be sent lossy to the client
2) when required, replacing lossy cache items with their correspending
lossless bitmaps
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This patch allows people to build the spice-client on any 32bit/64bit
architecture.
by Bryan Stillwell <bryan@bokeoa.com>
|
|
|
|
|
| |
The command line option is renamed from "cairo" to "sw", and
similarly all filenames and types from Cairo to Sw (and similar).
|
|
|
|
| |
We just use pixman_image_t as the "information about image data" structure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Pixman sometimes sets the ignored high byte to 0xff during alpha
blending. This is correct according to pixman specs, as the high
byte is ignored. However its not what windows expects, and it causes
unnecessary regions with non-zero high byte, causing us to
send rgba data instead of rgb which compresses worse.
So, we detect this and clear the high byte.
|
| |
|
| |
|
|
|
|
|
| |
The win32 driver makes all 32bit surfaces be xRGB now, so we
can remove this old workaround.
|
| |
|
| |
|
|
|
|
| |
This is needed since they always decode to 32bit mode.
|
|
|
|
|
|
|
|
| |
Surface creation now specifies the exact format, not only the bit depth
of each surface which is used for rendering.
Additionally we now actually store the surfaces in that format, instead
of converting everything to 32bpp when drawing or e.g. handling palettes.
|
|
|
|
|
|
|
|
|
|
|
| |
We now support 16bit format pixmaps as well as the old ones. Including
both 555 and 565 modes.
We drop the palette argument for pixmap construction as it was only
used for black/white anyway.
Canvas creation is simplified so that there is no separate set_mode
state. Canvases are already created in the right mode and never change.
|
|
|
|
|
| |
Ideally we should just read this from the pixman image, but
there is no API to do so in stable pixman, so we store it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The new command return dirty area to be used
by users that want spice to render localy or
into some framebuffer (sdl / vnc)
Signed-off-by: Izik Eidus <ieidus@redhat.com>
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Izik Eidus <ieidus@redhat.com>
|
|
|
|
|
| |
When blitting we don't really care about alpha mismatches, we just copy bits
anyway.
|