Handling done in red_channel instead of per channel, using call backs
for the channel specific part.
Intended to reduce furthur reliance of channels on RedChannel struct.
The commit makes the code harder to understand because of the artificial
get_serial stuff, should later be fixed by having a joint migration
header with the serial (since all channels pass it).
For ussage in the send_item callback. It's only valid during this
time anyway (should make it return NULL in other occasions?)
No more direct usage of RedChannel.send_data.marshaller by channels.
The renames are part of refactoring red_worker's RedChannel to reuse
red_channel.h's RedChannel at the end.
s/red_send_data/red_channel_send/
s/red_pipe_get/red_channel_pipe_get/
s/recive_data/incoming/
s/red_receive/red_channel_receive/
s/channel_handle_message/red_channel_handle_message/
s/channel_is_connected/red_channel_is_connected/
s/red_pipe_add_type/red_channel_pipe_add_type/
This is stylish change again. We are talking about a RedStream object,
so let's just name the variable "stream" everywhere, to avoid
confusion with a non existent RedPeer object.
https://bugs.freedesktop.org/show_bug.cgi?id=34795
s/disconnect_channel_proc/channel_disconnect_proc/
s/release_item_proc/channel_release_pipe_item_proc/
s/handle_message_proc/channel_handle_parsed_proc/
Adds RedChannel* channel as first parameter to hold_pipe_item_proc
with everything (almost) not in red_channel's RedChannel
As a result of CommonChannel a free cb is added to EventHandler,
to take care of non zero offset for embedded EventHandler.
hold_item called on init_send_data, matching release.
This is not the behavior of red_worker - we ref++ (==hold_item) when
sending the item, and --refs when releasing it, instead of only holding
if the send is blocked.
Note 1: Naming: hold_pipe_item is the proc name, the variable is called
hold_item, this is similar to release_item/release_pipe_item naming.
Note 2: All channels have empty implementation, we later use this when
red_worker get's RedChannelized.
drawable_count was becoming negative. It tracks the number of
items in the worker->current_list ring. It was decremented correctly,
but incremented only in several cases. The cases it wasn't incremented
where:
red_current_add_equal found an equivalent drawable
by moving the increment to where the item is added to current_list, in
__current_add_drawable, the accounting remains correct.
This has no affect other then correct accounting, as drawable_count isn't
used for anything.
When drawing a drawable with a NULL src bitmap that means we should
be using the previously generated self_bitmap. Not doing this causes
a segfault due to accessing the NULL.
The self_bitmap is the size of self_bitmap_area, not the bbox.
This is especially important since we later copy the self_bitmap_area
into the new bitmap, and if that is larger than bbox then we will
overwrite random memory.
We really need to flush the ring to ensure that we push something on the
release ring. If we don't do this and the ring is not pushed for other
reasons we will timeout in the guest driver waiting for the ring.
We've changed how resources are released so they are now being
freed continuosly, rather than on OOM, since we want to free as early
possible to avoid fragmentation. So, OOM situations should be a bit
less common now and signify a real memory shortage, so we should try
to free up more resources.
This will prevent: 1) rendering problems (commands sent to the client in the wrong order)
2) sending commands for surfaces that haven't been created yet on the client side.
A side effect of the previous red_current_flush, which flushed all the surfaces, and was called on a new display channel connection, was
that red_handle_drawable_surfaces_client_synced sent the most updated surfaces images when needed. However, now, it should
explicitly call red_current_flush.
Moreover, since red_current_flush was called on a new display channel connection only if there was a primary surface,
if the connection of the display channel occurred at the moment of no primary surface, red_handle_drawable_surfaces_client_synced was buggy.
