Create an async, and marshall the GL_DRAW message. Count number of
clients, and wait until gl_draw_async_count is 0 to complete the async.
The count is going to be updated in the following patch when the client
is done with the draw.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[removed unused sent field; move gl_draw_async_count to DisplayChannel
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Go through dispatcher and marshall scanout message. Since the marshaller
and the QXL state are manipulated from different threads, add a mutex to
protect the current scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
- spice_qxl_gl_scanout() to take the current scanout
- spice_qxl_gl_draw_async() to draw the scanout, is like other Spice async
functions, it takes a cookie and will return in the
QXLInterface.async_complete()
Two new fields are also added to QXLState, in order to save the current
scanout, and the pending async.
A scanout can't be updated if there are pending draw atm. Discarding
outdated draws is left as a future improvement to allow updating the
scanout without waiting for draw async to be done.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[make QXL function names more coherent - Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Instead of using CPU time use a timer depending on real times.
Currently that time in the record log is not used.
However if we want to reproduce problems with stream would be useful
to have real times instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Now that processing is correctly restored there is no need to keep
polling to avoid main loop hangs. Reduce the polling count to 1
(just try once).
This reduce cpu usage if guests are mainly idle.
If you consider 100 guests waiting to login with cursor blinking
and considering the polling was done 200 times every 10ms (maximum)
just the cursor blinking was causing 10100 loop iterations per second
while now only 200 are needed (considering cursor blinking every
second).
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure we process commands after we can send data to client.
If during processing we detected that there was too much data in the
clients queues the processing of commands just stop till the next
iteration.
However if all data are pushed in a single iteration of the loop
and commands were already processed there was the (remote) possibility
that the loop hangs till a separate event (like a screen resize on
client window) arrive.
I manage to reproduce and after half an hour no events arrived.
This patch detect that processing was stuck and now we can process new
commands and force a new iteration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The req_cmd_notification callback is called by spice-server when it
has processed all commands and wants to be notified (by a wakeup) that
new commands have been appended to the command queue.
Replay utility tries to fill the commands when it detects that
spice-server is trying to read commands but there are no more commands.
However, new commands are appended in a separate thread so if the main
red worker loop on spice-server is really tight this request can
happen.
Avoid printing any message on this condition, message will be appended
and loop woken up when replay code can do it.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
During every iteration of the main worker loop, outgoing data was pushed to
the client. However, there was no guarantee that the loop would be woken up
in every situation. So there were some conditions where the loop would stop
iterating until a new event was sent.
Currently, the events that can wake up the main worker loop include:
- data from dispatcher (including wakeups from the guest)
- data from clients
- timeouts on a stream
- other timeouts
- polling
This patch adds a new wakeup event: when we have items that are queued to
be sent to a client, we set up a watch event for writing data to the
client. If no items are waiting to be sent, this watch will be disabled.
This allows us to remove the explicit push from the main worker loop.
This has some advantages:
- it could lower latency as we don't have to wait for a polling timeout.
From my experiments using a tight loop (so not really the ideal
condition to see the improvements) the total time was reduced by 2-3%)
- helps reduce the possibility of hanging loops
- avoids having to scan all clients to detect which one can accept data.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch use old code to implement timer events.
The new version use some function from GLib 2.34 however some systems
(like RHEL 6) have former GLib version (RHEL 6 has GLib 2.28 installed)
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Since this is public API, we can't easily change the signature of the
function to take a RedsState argument, so instead we apply a hack and
store the reds argument inside the device state struct when the
interface is added, and retrieve it for use later when it is removed.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Send the fd associated to the last message sent.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The default rule being "all", it builds noinst_PROGRAMS but not
check_PROGRAMS. Let's build all the tests by default.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Was used to just assure there was at least one renderer in the list.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Use the glib mainloop instead of writing our own. The glib loop is both
cleaner to use and is more extensible. It is also very mature and
reduces the maintenance burden on the spice server.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>