Re: [Qemu-devel] Ongoing changes to the displaying code

[David Turner <digit@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

Hello Anthony,

On Fri, Jan 9, 2009 at 4:20 PM, Anthony Liguori <anthony@codemonkey.ws>wrote:

> I would think the ability to maintain your own GUI and therefore not have
> to fork QEMU would outweigh the "overkill" factor.
>
> What specifically, do you consider to be overkill?  Are you afraid of the
> performance overhead of VNC?  Is the lack of VNC clients a problem (assuming
> you don't want a gtk dependency)?
>

Given that there is only one person that works on the Android emulator (me),
and that this is unlikely to change in the near future,
I want to avoid any additional complexity with low return on investment
(development / support costs).

Simply put it:

I want something simple that "just works" on three different platforms.
I absolutely cannot use a standard VNC client.
I want to distribute the program as a single statically linked executable.
I don't want a GTK/Qt/Whatever dependency.
I can test my UI on one platform and know that it will look and behave
exactly the same on other ones
(e.g. no funky behaviour due to slightly different fonts, different versions
of the UI toolkit libs, whatever).

I could change my mind on various of these items, but this would invariably
require more (or even a lot more) development and support efforts

Finally, the program is *already* accessed and controlled by an external
Java development tool (DDMS) which has sophisticated UI elements

Fortunately for me, it's a very specific application that doesn't require a
full-blown GUI, and never will :-)
I'm not advocating this path for other projects, just explaining what I do.


>
>
>  On the other hand, it would be nice to have a slightly better way to
>> decouple display/events between the emulation and user-interaction parts of
>> the system. For example, I've attached the framebuffer abstraction that I
>> currently use in the Android emulator source code (it's a well documented
>> header file).
>>
>> It's basically a slightly better DisplayState, with explicit
>> producer/clients relationships and a global fifo used for
>> initialization/linking. I do not claim it is the absolute best way to do it,
>> just an example on how this can be implemented.
>>
>
> I'd like to avoid introducing another remove communication mechanism in
> QEMU.  VNC is extremely flexible so we should be able to do whatever we need
> to do with it.
>

Oh, this is not a remote communication scheme at all. This is only a header
used to completely decouple the emulation part of the program from the one
sending it to the display. it's only better than the current scheme because
the UI part doesn't need to include emulation-specific headers just to get
the definition of DisplayState, and the role of each party is more clearly
documented.

Regards,

- Digit

[-- Attachment #2: Type: text/html, Size: 3555 bytes --]