Since some spice C++ code is using code from common/, the C
functions need to be marked as such for the C++ compiler, otherwise
we'll get linkage issues.
clang static analyzer warned that 'len' was computed but never
used in glc_vertex2d. glc_stroke_line_dash has side effects so
we have to call it, but we don't need to save its return value
since it's not used.
move all the ASSERT/PANIC/PANIC_ON/red_error/red_printf* macros
to a common file to be used with ring.h that is going to be used externally
(by spice-gtk).
This is the only unused var change I'll want to revisit eventually,
I'm submitting anyway since it doesn't change current behavior. I'm
talking about ignoring the return value from canvas creation. Adding
a print is possible but I didn't test (may be too verbose, also
preferable to be a debug print if so, and we don't have that option
in the code atm - probably an environment variable will do, or adding
some spice_server_set_logging_level api, maybe even
spice_server_set_logging_fd?)
Allow top_down flag to have any value, only ASSERT it is positive
when needs to be positive and zero otherwise. Allows older server
bug of sending 4 instead of 1 in top down flag to not affect newer
clients (previous patch fixes server).
When scaling part of an image we need to specify the source
coordinates in transformed coordinates. For large magnifications this
means we will get pretty large values.
Now, if e.g. src_x * transform is larger than 32765, then the
coordinate ends up outside the pixman 16bit image size, so the
rendering will not work.
The fix is to make the src_x/y offset part of the transformation.
This means its automatically transformed by the correct scaling, and
the coordinates passed into pixman are not (typically) over 16bit.
When scaling part of an image we need to specify the source coordinates
in transformed coordinates. For large magnifications this means
we will get pretty large values.
Now, if e.g. src_x * transform is larger than 32765, then the coordinate
ends up outside the pixman 16bit image size, so the rendering
will not work.
In order to work around this we generate a "sub-image" of the pixman
image such that the src_x/y values we have to specify are zero (or near
zero).
When scaling in pixman you give the source coordinates in transformed
space rather than in the source coordinates. This is a bit problematic
when both source and destination coordinates are at integer positions, but
the scaling factor is not an exact 16.16 fixed point value. We used
to calculate the transformed source based on the floating point
transformation, which gave the wrong answer sometimes. Now we do the
calculations based on the fixed point transform that we give pixman.
However, even with this patch I can still sometimes see issues related
to this, although they are less bad.
Remove all uses of @end in the marshaller, instead just using
the C struct array-at-end-of-struct. To make this work we also remove
all use of @end for switches (making them C unions).
We drop the zero member of the notify message so that we can avoid this
use of @end for a primitive in the marshaller (plus its useless to send
over the wire).
We change the offsets and stuff in the migration messages to real pointers.
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.
