#96 DirectDraw support only works at 32 bits

[Lloyd Lim]

DirectDraw support only works on mr-bill when the
monitor is set to a bit depth of 32.

When the bit depth is 24, a full size RTPtv image looks
ok, but the thumbnail image appears skewed.

When the bit depth is 16, all images are clearly the
wrong colors.

The blue test screen displays correctly at all bit
depths, but when you use an RTPtv stream you can see
the problems. Therefore, there are probably problems
in the red and/or green components.

Behavior was consistent regardless of the number of
monitors used (tested with 1 or 2) and regardless of
the version of Windows (tested with 95 and 2000).

This is my bad. I should have tested the other bit
depths more thoroughly.

[Matthew Delco]

Logged In: YES
user_id=169966

In XP, my driver only supports 16-bit and 32-bit (no more
24-bit). Anyway, this initially appears to be due to
differences in opinion between mash & hardware for what
exactly 24-bit and 16-bit color is.

For example, at 16-bit mash appears to use 6-5-5:

r fc00 1111 1100 0000 0000
g 03e0 0000 0011 1110 0000
b 001f 0000 0000 0001 1111

DirectDraw (at least for my hardware) uses 5-6-5:

r f800 1111 1000 0000 0000
g 07e0 0000 0111 1110 0000
b 001f 0000 0000 0001 1111

So, 16-bit will take some work to get running in mash. 24-
bit potentially has a RGB versus BGR issue, but I'm not
sure how to properly affect what rgb conversion is
selected in mash. Given problems with 24-bit, you'd think
that 32-bit would have even more problems. But it doesn't-
-a small favor, or bug in disguise?

The quickest "fix" is to change Tk_Depth(tk)>=16 to
Tk_Depth(tk)>=32 in vw.cc. The proper approach for a more
complete implementation for supporting other bits has yet
to be determined.

[Matthew Delco]

zip of files: vw.h and vw.cc for enhanced DDrawOkay, color-hi.cc for bit check, and video-test.cc for new color possiblities

[Matthew Delco]

Logged In: YES
user_id=169966

I'm sorry to throw this code "over the wall", but it's all
I have time to do right now--someone will need to port in
the code to CVS. I might have time to do it (eventually),
but I first want to get permission for this code approach
to be used.

Basically, the bits in mash and directX don't agree. So,
my initial fix is as follows (it only fixes 16-bit, so
far):

1) Have DDrawOkay() look at (and store) the r,g,b bits
that are used by hardware (also now checks to make sure
that all devices uses the same r,g,b bit order/length).

2) Have the 16-bit yuv->rgb conversion code (in
HiColorModel::alloc_colors() ) call DDrawOkay to see if
DirectDraw is in use

3) If directdraw is in use, then the 16-bit conversion
code will use the device bits (stored by DDrawOkay)
instead of the default bits that are defined for 16-bit
color.

This change works fine for me (under mild testing). I've
also attached a new test capture device that does blue,
purple, yellow, green, and red.

Possible issues: since the 16-bit colors flags are defined
for DirectDraw, this means that any non-DirectDraw windows
will now be using the wrong color palette. I'm also using
the GetDesktopWindow() to get a HWND in
HiColorModel::alloc_colors(). I'm not sure if this is
legal or appropriate.

Alternatives: use DirectDraw only for 32-bit (or perhaps
24-bit depending on how it needs to be fixed). There is
MMX yuv->rgb code in mash for these higher bit depths; I
don't recall if/how this code is enabled (or how well it
works). So, we could just treat 32-bit as a high-
performance mode in mash: you get MMX and DirectDraw only
at this depth.

[Matthew Delco]

Logged In: YES
user_id=169966

For clarity: the necessary files for (manually) diffing
into CVS are available for download via the sourceforge
web page.

Also, I should clarify what I mean by "any non-DirectDraw
windows will now be using the wrong color palette". This
bit order/length issue will only be a problem for non-
DirectDraw windows if DDrawOkay returns true, but a non-
DDraw window is allocated anyway (such as for a window
that's too small, or one that's not a certain multiple of
pixels wide). Otherwise, if DDrawOkay returns false then
DDraw won't be used and the bit lengths/order will remain
unchanged and thus not mess up non-DDraw windows.

[Lloyd Lim]

Logged In: YES
user_id=99220

I need to look into this issue more and think about it more,
so I'm assigning this bug to me, for the time being.