From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLKbh-0006yD-Cq for qemu-devel@nongnu.org; Fri, 09 Jan 2009 11:53:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLKbg-0006y1-Px for qemu-devel@nongnu.org; Fri, 09 Jan 2009 11:53:13 -0500 Received: from [199.232.76.173] (port=43114 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLKbg-0006xy-Lz for qemu-devel@nongnu.org; Fri, 09 Jan 2009 11:53:12 -0500 Received: from smtp-out.google.com ([216.239.45.13]:30304) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLKbg-0000Mh-38 for qemu-devel@nongnu.org; Fri, 09 Jan 2009 11:53:12 -0500 Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id n09Gr9lH014390 for ; Fri, 9 Jan 2009 08:53:09 -0800 Received: from yx-out-1718.google.com (yxh36.prod.google.com [10.190.2.228]) by spaceape13.eur.corp.google.com with ESMTP id n09Gr5XB025859 for ; Fri, 9 Jan 2009 08:53:06 -0800 Received: by yx-out-1718.google.com with SMTP id 36so3551998yxh.22 for ; Fri, 09 Jan 2009 08:53:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <49676B43.2020406@codemonkey.ws> References: <4966ADD4.5090102@codesourcery.com> <4966BB7A.3090303@codemonkey.ws> <4966BEC4.7080903@codemonkey.ws> <60cad3f0901090128m23977527kf658c15ba90dbaf8@mail.gmail.com> <49676B43.2020406@codemonkey.ws> Date: Fri, 9 Jan 2009 17:53:05 +0100 Message-ID: <60cad3f0901090853j5a32072cr1be7d44730fc608f@mail.gmail.com> Subject: Re: [Qemu-devel] Ongoing changes to the displaying code From: David Turner Content-Type: multipart/alternative; boundary=00151750eeba46614b04600f9773 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --00151750eeba46614b04600f9773 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Anthony, On Fri, Jan 9, 2009 at 4:20 PM, Anthony Liguori 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 --00151750eeba46614b04600f9773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Anthony,

On Fri, Jan 9, 2009 at 4:2= 0 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
=
I would think the ability to maintain your own GUI and therefore not have t= o 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 fut= ure,
I want to avoid any additional complexity with low return on invest= ment (development / support costs).

Simply put it:

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

I could change my mind on various of these items, but this would invari= ably require more (or even a lot more) development and support efforts
<= br>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 t= his path for other projects, just explaining what I do.
 = ;


On the other hand, it would be nice to have a slightly better way to decoup= le display/events between the emulation and user-interaction parts of the s= ystem. For example, I've attached the framebuffer abstraction that I cu= rrently use in the Android emulator source code (it's a well documented= header file).

It's basically a slightly better DisplayState, with explicit producer/c= lients relationships and a global fifo used for initialization/linking. I d= o not claim it is the absolute best way to do it, just an example on how th= is 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 th= e 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 emulati= on-specific headers just to get the definition of DisplayState, and the rol= e of each party is more clearly documented.

Regards,

- Digit
--00151750eeba46614b04600f9773--