Date   : Sun, 25 Jan 2004 14:59:19 +0000
From   : Richard Gellman <splodge@...>
Subject: Graphics Rendering in BeebEm

Hi

I'd like to collate opinion on dropping the old GDI interface for the 
graphics rendering of BeebEm. The problem is this:

The current BeebEm model involves a windows bitmap in memory, which 
realizes a pallette of 8 BBC Colours (Black, red, green, yelow, blue, 
magenta, cyan, white) and roughly 6 or so Windows colours used to 
display things like the FDC plugin in use, speed/FPS display, keyboard 
and disc LEDs, etc.At screen update time, this is stretch-blitted either 
directlt to the screen in non-directdraw mode, or into a DirectDraw 
surface representing the screen.

This is not only slow, but also results in a judder effect as the eye 
catches the screen in mid-update (no *FX 112/3 tricks for us). The 
better option (and the one favored by most DirectDraw users) is to use 
page flipping (A%=113:CALL &FFF4...). The DirectDraw subsystem takes 
care of keeping pointers in check, but stretch-blitting into the 
backbuffer is hideously slow. A direct blit speeds things up slightly, 
but results in an _interesting_ display...

To summarise all this, the ideal DirectDraw model interferes with the 
ideal GDI model. I would like to remove GDI (non-directdraw) support 
from BeebEm, and move to a more pure model, implementing a BBC Screen 
buffer (sans windows bitmap objet headers) and a custom-made blitter to 
get the data into a 32-bit backbuffer.

All of this does not affect the ability to do windowed mode, this 
feature would not be dropped.

So, after all this great long explanation, whats the general opinion on 
dropping GDI support?

-- Richard Gellman