Start reducing the usage of spice_new*/spice_malloc allocations.
They were designed in a similar way to GLib ones.
Now that we use GLib make sense to remove them.
However the versions we support for GLib can use different memory
allocators so we have to match g_free with GLib allocations
and spice_* ones (which uses always malloc allocator) with free().
This patch remove some easy ones.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
If you are testing for NULL data this means that variable could be
NULL so avoid to access before the check to make sure the check is hit.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This commit changes all functions returning TRUE/FALSE from having an
'int' return value to 'bool'.
This way it's obvious that such a function is not going to return
anything else than TRUE or FALSE.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Use new structures and functions to implement the statistics code.
Use inline functions instead of macros for increased type-safety.
If statistics are disabled, the structures and functions become
empty. This confines the configuration-specific #defines to the
statistics implementation itself and avoids the need for #defines in
the calling functions. This greatly reduces the chance of accidentally
breaking the build for one configuration or the other. The reds option
was removed from stat_inc_counter() as it was not used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
When the initial image was sent to the client the reference
was not incremented leading to some user after free.
This regression was introduced in
3bde2e570c
("DCC: remove more init_send_data() arguments").
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This third argument (and the 'item' member of
RedChannelClient::priv::send_data) was a somewhat roundabout way to keep
the RedPipeItem alive until a message is sent, just in case some data
owned by that pipeitem was added to the marshaller by reference. This
was a rather confusing mechanism, however, since it did not have any
obvious connection to the _add_by_ref() call. It was never very clear
whether you needed to pass an item to this function or not. The previous
series of patches made this parameter unnecessary since the referencing
of the pipe item (or other related structure) is now more explicitly
connected to the calls to spice_marshaller_add_by_ref_full().
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The fill_bits() function marshalls some data by reference. This data is
owned by the RedDrawable that is owned by the Drawable that is owned by
the RedDrawablePipeItem. Instead of keeping the RedPipeItem alive by
passing it to red_channel_client_init_send_data(), simply reference the
Drawable and marshall it with _add_by_ref_full(). This means that we
can't use the _add_chunks_by_ref() convenience function since that
function doesn't allow us to pass a free function to clean up the data
after it is sent.
This change is not perfect since the fill_bits() function makes an
assumption that 'simage' is owned by the 'drawable'. On the other hand,
the previous code made a much bigger assumption: that the caller would
ensure that the data would be kept alive
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The spice_marshaller_add_ref() family of functions is confusing since it
sounds like you're incrementing a reference on the marshaller. What it
is actually doing is adding a data buffer to the marshaller by reference
rather than by value. Changing the function names to _add_by_ref() makes
this clearer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The video encoders already have sophisticated bit rate control code that
can react to both stream reports sent by the client, and server frame
drop notifications. Furthermore they can adjust both the frame rate and
the image quality to best match the network conditions.
But if the client cannot send stream reports all this is bypassed and
instead the streaming code performs its own primitive bit rate control
that can only adjust the frame rate.
So this patch removes the code duplication and lets the video encoders
do their job.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Include common and libraries includes before local ones as
stated by style.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
These functions were implementing the same stuff as empty
messages functions provided by RedChannel so reuse them.
The implementation seems a bit different but the result
is the same. Specifically:
- RedEmptyMsgPipeItem::msg is int while RedVerbItem::verb was
uint16_t however this data goes into the message type which
is uint16_t (a 16 bit on the network protocol);
- red_channel_client_send_empty_msg calls
red_channel_client_begin_send_message while red_marshall_verb
does not. However red_marshall_verb is called only by
cursor_channel_send_item and dcc_send_item which always
calls red_channel_client_begin_send_message.
Note that in dcc_send_item when an empty message is sent
red_channel_client_send_message_pending always returns
true;
- when a PipeItem is created red_channel_client_pipe_add_empty_msg
calls red_channel_client_push while red_pipe_add_verb does not.
This actually make very little difference as this kind of item are
never removed from the queue and a push is forced in every case
running the event handler for the stream watch (see
prepare_pipe_add and red_channel_client_event).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The check for free_list->wait.header.wait_count was always true.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Instead of using a Ring (and having a ring item link in every pipe
item), store them in a GQueue. This also necesitated changing
RedCharDeviceVDIPort->priv->read_bufs to a GList as well.
Also Optimise client pipe by passing pipe position instead of data.
This avoids having the search the data scanning all the queue changing
the order of these operations from O(n) to O(1).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Move all of the DisplayChannel data memembers into a private struct to
encapsulate things better. This necessitated a few new 'public' methods
and a small bit of refactoring to avoid poking into DisplayChannel
internals from too many places. The DisplayChannel and the
DisplayChannelClient are still far too intertwined to completely avoid
accessing private data, so at the moment the private struct is defined
in display-channel.h and the DisplayChannelClient implementation
still accesses it sometimes.
These need to be introduced at the same time since cache-item.tmpl.c
assumes that both of these classes will have a cache in the same place:
either within the channel client struct itself or (now) within a priv
struct owned by the channel client.
This encapsulates private data and prepares for porting to GObject.
Acked-by: Frediano Ziglio <fziglio@redhat.com
Don't poke into the structure to get the channel
This prepares for encapsulating RedChannelClient a bit more and
separating it into its own source file.
The field is only used by DisplayChannelClient, not by CursorChannelClient
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add a few more methods and accessors so that other files don't need to
manipulate the struct members directly. Move the struct definition to a
private header which only the dcc-* files will include.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Without a video encoder no frame will be streamed anyway.
This fixes the case where the client does not support any of the
server's codecs, such as if it was compiled with --enable-gstvideo=no
--disable-builtin-mjpeg.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Note that we can only avoid copies for the first 1 Mpixels or so.
That's because Spice splits larger frames into more chunks than we can
fit GstMemory fragments in a GStreamer buffer. So if there are more
pixels we will avoid copies for the first 3840 KB and copy the rest.
Furthermore, while in practice the GStreamer encoder will only modify
the RedDrawable refcount during the encode_frame(), in theory the
refcount could be decremented from the GStreamer thread after
encode_frame() returns.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This way the video encoder is not forced to use malloc()/free().
This also allows more flexibility in how the video encoder manages the
buffer which allows for a zero-copy implementation in both video
encoders.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The Spice server administrator can specify the encoder and codec
preferences to optimize for CPU or bandwidth usage. Preferences are
described in a semi-colon separated list of encoder:codec pairs.
The server has a default preference list which can explicitly be
selected by specifying 'auto'.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
The server picks a codec supported by the client based on the following
new client capabilities:
* SPICE_DISPLAY_CAP_MULTI_CODEC which denotes a recent client that
supports multiple codecs. This capability is needed to not have to
hardcode that MJPEG is supported. This makes it possible to write
clients that don't support MJPEG.
* SPICE_DISPLAY_CAP_CODEC_XXX, where XXX is a supported codec. Note
that for now the server only supports the MJPEG codec.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
encode_frame() needs the QXL_DRAW_COPY operation's SpiceCopy.src_area
field anyway, so the width and height parameters were redundant.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Only red_marshall_stream_data() needs to know whether to send the frame
using a SpiceMsgDisplayStreamDataSized or a regular StreamData message.
So check whether we have a sized frame there and simplify the rest of
the code.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This code just refactors the function without doing any functional
changes. The actual changes will be in the next commit, and this will
make the next commit much more obvious.
The id type is already uint64_t, no need to cast using some low
level casts.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This was proposed by Christophe as improvement over some typesafe
patches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Scan remaining code searching for problems with structure
layout assumptions in the code.
Where code required some restructuring put some verify checks
to make sure code won't compile if these assumptions are not
in place anymore.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Remove the need to release the item inside send_item callbacks.
This looks like a partial rollback of previous patch but is
to make clear the intention of the change.
The lifetime of items could extend a bit further but there
are no cases this small lag should cause problems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
