Re: [Qemu-devel] [PATCH 01/42] ui/sdl2 : initial port to SDL 2.0 (v2.0)

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > +if test $sdlabi == "2.0"; then
> 
> Please replace '==' by a single '=' here. dash (and maybe other less
> sophisticated shells) don't like '=='.

I'll fix it up.

> I know that sdl2.c is based on sdl.c which was coded before the
> introduction of the current coding rules, but would you mind if I send a
> follow-up patch which fixes the warnings from checkpatch.pl for sdl2.c?

It's in the series already, pretty close to the end, should be easy to
find as it carries "checkpatch" in the $subject.

> Some of the other patches don't include a Signed-off-by, so those
> patches are only ready for local testing.

I'll have a look before sending out the next version (I expect I need at
least one more iteration with cocoa fixes anyway ...).

> I was very curious to get test results here in my environment because of
> a strange effect which I had noticed recently: booting a Linux system
> (Tiny Core Linux) with SDL 1.2 (1:06) takes twice as long as with GTK
> (0:33) or curses (0:29). The test was run on a remote Linux x86_64
> server (so X display output is slower than normal). The huge difference
> is not caused by more activity but simply by delays were the QEMU
> process is waiting.

The SDL API is synchronous.  For remote X11 perform reasonable well you
must operate asynchronously.  So that is a really bad fit.

We might be able to workaround that by running SDL in a thread, so SDL
doing a (blocking) wait on the remote X-Server doesn't disturb the qemu
iothread.

But at the end of the day you are much better off using vnc or spice for
a remote display, even in case SDL runs threaded some day.  For starters
vnc only sends over the parts of the screen which did actually change.
vnc also knows when the network link is saturated and skips frames then.

cheers,
  Gerd