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.
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
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.
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.
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>
While the fix could have been more effective,
it seems like this patch stream better with the coding
logic that was there..., maybe later we will want to change
the locking into more effective way.
(There is just the primary surface to protect in reiality)
Signed-off-by: Izik Eidus <ieidus@redhat.com>
BitmapMask was used by the draw_text function as well
therefore we need to mark from_surface = 0 if we want
it to release the boject...
(Was evil, took me few hours to understand from where
the leak come...)
Signed-off-by: Izik Eidus <ieidus@redhat.com>
We rely on not passing on empty rects to the drawing operations by
checking for empty regions and exiting early. However the checks
were wrongly using pixman_region32_n_rects(region) == 0, whereas
we should be using pixman_region32_not_empty().
Every place that does a regular malloc/calloc and aborts on failure
should use spice_malloc/spice_mallo0 instead, which is leaner and cleaner.
Allocations of dynamically sized arrays can use g_malloc_n or g_new etc
which correctly handle multiplication overflow if some of the arguments
are not trusted.
This adds a set of virtual methods for low-level operations. A subclass
can choose to implement those and let the default CanvasBase implementations
handle the highlevel stuff.
Instead of having two virtualizations of the canvas we push the
virtualization into the canvas code itself. This not only avoids
the duplication of this code, it also makes the exposed API for the
canvas much smaller (in terms of exported API).
It also lets us use the virtualization to implement basic support
for operations in canvas_base which is then overridden by each canvas
implementation.
We were masking out the alpha bit in the key color not int
the source pixel, so colorkeying didn't work when the high byte
was != 0. For instance in the shutdown dialog in XP.
