From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=47529 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OE0Oj-00033f-GE
	for qemu-devel@nongnu.org; Mon, 17 May 2010 09:30:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OE0Oi-0001SE-4b
	for qemu-devel@nongnu.org; Mon, 17 May 2010 09:30:21 -0400
Received: from mail-gy0-f173.google.com ([209.85.160.173]:44452)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OE0Oi-0001S6-1W
	for qemu-devel@nongnu.org; Mon, 17 May 2010 09:30:20 -0400
Received: by gyd5 with SMTP id 5so2153606gyd.4
	for <qemu-devel@nongnu.org>; Mon, 17 May 2010 06:30:19 -0700 (PDT)
Message-ID: <4BF144E2.1050609@codemonkey.ws>
Date: Mon, 17 May 2010 08:30:10 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
References: <1273766038-16808-1-git-send-email-julian.pidancet@citrix.com>
	<201005160210.25323.paul@codesourcery.com>
In-Reply-To: <201005160210.25323.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, Julian Pidancet <julian.pidancet@citrix.com>

On 05/15/2010 08:10 PM, Paul Brook wrote:
>> The other solution would be to use the DirectFB driver for SDL which
>> would allow to do slightly the same as this patch. But that would mean
>> having to deal with an additional layer in the graphical stack, which is
>> not exactly what one wants from a performance or a complexity point of
>> view.
>>      
> I don't buy your complexity argument.  Doesn't DirectFB-via-SDL already work?
> If not why not? I'm pretty sure fixing that would be way simpler than adding a
> whole new output backend.
>    

Yeah, I don't buy it either.  I think performance data is probably the 
only way to justify this and I'm sceptical that if there is a 
performance advantage that it wouldn't be possible to just fix SDL's 
DirectFB support.

Regards,

Anthony Liguori

> Paul
>
>