From mint-bounce@lists.fishpool.fi Thu Dec 10 07:35:50 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=zronJV+G0nJuhMPgrSdu5R6UDBj9zRMGrAeTLpMJfCM=; b=hqo+ouFCzFg9K3ehRlKv0xKwEeIwUmkkpuioqh4L1vFrqsseXBQgGYdUXlPXG8aFZX ubDYck+/8cuu81ufprpjqI0+lMZ1DY834lobXA38coM2k1kMUO5qIwGJWHXgKbHBp7Z+ 7C9pNrG80wGnVPFdFONooHS4FrtV7JdLEcsAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=x6ZtIaxzzCpz6jLP/80asytuEQUBn35rVKhkaVcfArPNfTODZO45RaK4HivTeB3+ZN m2Lu7TbckiuasWF0QpZlaAQ7uGGrmNEfFCfjnBw+5r7/EbLFfCNRSZOKPDoPuJp7gHlK r5Ze617AUm8hMd6ffN1L/DieXjgxMK4fyCo3U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 From: Peter Persson In-Reply-To: Date: Thu, 10 Dec 2009 13:32:09 +0100 Message-Id: References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <11a6f2b10912081349x51b88c71p278c085ff9b77f2e@mail.gmail.com> <11a6f2b10912082333g5ede94a6t862ff00a111c970a@mail.gmail.com> <7116AF0ECE9F4F099B489E49FEE856FC@mercatus.local> <4B1FBAB0.4080607@freesbee.fr> <78830890-DD21-4A08-AA55-F9D4A0F186B2@gmail.com> To: "[MiNT] Mailing-List" X-Mailer: Apple Mail (2.1077) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id nBACZoX4008181 On 10 dec 2009, at 11.08, Johan Klockars wrote: > I want to prevent it exactly to avoid this existing source of > incompatibility (and to improve speed on modern hardware), which you > just mentioned. We can't just ignore the current software base. And just because this can't be done on Eclipse or Aranym, there is no need to prevent access to the framebuffer on systems where this is possible. That would just generate problems instead of solving them. > There's no reason why the C2P could not be done by the VDI while > blitting. Granted, doing less than all the planes is not something > that would be useful in more "normal" cases, but I still would not > have any problems with the VDI doing that. > I was actually experimenting with using less than four planes for text > windows in 16 colour mode on my Falcon in the early days of fVDI. ;-) I wouldn't mind having this kind of functionality in the OS, as long as the performance is good on both legacy graphics hardware and modern accellerated dito. It would also have to be implemented in an extremely flexible manner, to cater for stuff like the things I described earlier. Ok, I'm 90% on the same page as you. We could argue about those 10% - or save that for later and focus on the other 90%. -- PeP