Re: [AD] windowed mode patch

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Isaac Cruz <icruzbal@xxxxxxxxxx> writes:
> - new global variable, desktop_color_depth (only in Windows code)

Could we do this as a function in the system driver instead? I think it 
might be useful for some other platforms, like Grzegorz suggested. I'll 
change this while applying the patch, as long as you don't mind me screwing 
up your code in that way :-)

I'm not sure how directly the color depth will apply to X code, as not all X 
hardware even has a single global color depth setting (Michael? Is there 
a call that can tell us this without having to create a window first?), but 
it could certainly be useful for other windowed environments (BeOS springs 
to mind).

> I think I could implement a dirty mechanism, but in what functions should 
> I check changes in offscreen buffer? I think in locking and in accelerated 
> functions.

The gfx_directx_write_bank() function (in wddlock.c) will be called once per 
scanline, before any software drawing onto the surface. It's an asm calling 
convention: passed the bitmap pointer in %edx and a y line number in %eax, 
returning a pointer to where you are supposed to draw in %eax, and not 
allowed to clobber any registers at all. You can use this to set flags in a 
dirty list (eg. "scanline_dirty[%eax] = TRUE"), although beware of 
sub-bitmaps, because if someone draws onto a sub-bitmap of the screen, the y 
coordinate passed to this function can be in something other than 
screen units (add bmp->y_ofs to convert).

The only other thing that can alter the image contents is hardware 
accelerated drawing functions, which are all in wddaccel.c, and don't go 
through that scanline locking mechanism.

Speaking of which: is it worthwhile to have a hardware accelerated hline() 
function? I added this two WIP's ago, and it is slightly faster than 
software on my machine, but on my work system it is actually much slower 
than software (because the DDraw call overhead is greater than the cost of 
software drawing for such a small area). It would be useful if other people 
could check the performance difference of hline() and circlefill() in 
test.exe, and see if they are faster with or without using the accel driver, 
so we can decide whether it is worth keeping this hline() implementation...

Anyway, this looks like some great work: keep it up!


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."