I have a mirror driver that’s using a device managed surface and punting
back to EngXxx functions. Using a usermode process i’m also able to save the
buffer to a .bmp file and see the results. When the driver’s in 32/24 or 16
bpp mode the .bmp of the buffer looks just fine. If I switch to 8bpp all
caption bars drawn on my surface don’t show any banding, which is what I’m
expecting. (kinda what you see when you take a screenshot of your desktop
and save it as an 8-bit bmp) Here’s an actual part of the .bmp created using
the contents of the buffer used for the surface in the mirror driver: http://img97.imageshack.us/img97/5665/gradient6pp.png
Instead it’s drawing a sort of mask on top of every caption bar. The palette
I’m using in 8 bit mode is the same as used in the perm2/3 examples (the 20
static colors and 236 other colors generated using a simple loop). Other
parts of the screen look like they are supposed to, it only happens for
caption bars. I stumbled across this sentence in the DDK “The Windows 2000
(and later) Shell uses gradient fills on all caption bars.” On that same
page it also says “For an 8-bpp surface, GDI does not call the driver’s
DrvGradientFill function.” I hooked DrvGradientFill anyway, but as expected
it never got called once.
Anybody know what’s going on here? I just want it to draw the caption bars
“normally” in 8 bpp mode, so it shows banding instead of this pixel pattern.
Just another quick question: The DDK example mirror driver shows setting the
GCAPS_PALMANAGED flag when in 8 bpp mode. I removed this flag because it
would cause all caption bars on the primary display to be drawn using a
solid color. Microsoft’s Netmeeting mirror driver also causes this to
happen. Should mirror drivers be using GCAPS_PALMANAGED at all?
I have a mirror driver that’s using a device managed surface and punting
back to EngXxx functions. Using a usermode process i’m also able to save the
buffer to a .bmp file and see the results. When the driver’s in 32/24 or 16
bpp mode the .bmp of the buffer looks just fine. If I switch to 8bpp all
caption bars drawn on my surface don’t show any banding, which is what I’m
expecting. (kinda what you see when you take a screenshot of your desktop
and save it as an 8-bit bmp) Here’s an actual part of the .bmp created using
the contents of the buffer used for the surface in the mirror driver: http://img97.imageshack.us/img97/5665/gradient6pp.png
Banding sucks. You get that in the situation you described because the
bitmap mapping process does a simple “find closest color operation”.
However, when the actual drawing is done, it’s done using solid brushes
with various shades of color. When you draw on an 8-bit surface with a
solid brush that is not directly found in the palette, the drawing is
done using a technique called “dithering”. Dithering creates an 8-by-8
brush using a mix of the two palette colors that are closest to the
desired color. Dithering is a sophisticated process that produces much
better visual results than banding.
Anybody know what’s going on here? I just want it to draw the caption bars
“normally” in 8 bpp mode, so it shows banding instead of this pixel pattern.
Why do you think the banding is “normal”? If you change your desktop to
an 8-bit mode, you’ll see exactly that same dithering in the caption
bars. Seriously, dithering=good, banding=bad.
Just another quick question: The DDK example mirror driver shows setting the
GCAPS_PALMANAGED flag when in 8 bpp mode. I removed this flag because it
would cause all caption bars on the primary display to be drawn using a
solid color. Microsoft’s Netmeeting mirror driver also causes this to
happen. Should mirror drivers be using GCAPS_PALMANAGED at all?
Do you expect to support palettes in your mirror driver?
It’s interesting to me that graphics displays have come so far in the
last decade that dithering and palette management is no longer
recognized. Ten years ago, virtually every display was 8 bit, and
dithering was something that display drivers knew intimately.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for clearing up about what is going on Tim. I agree that dithering
looks better than banding, but what would I have to change in order for
banding to occur (netmeeting/pcAnywhere and other remote admin tools show
banding in the caption bar when in 8 bit mode, I wonder if they did that
deliberately)? You might ask yourself why i’d want banding to occur… If
the the window title is long and a window is now the active window it’s
sometimes hard to read the last part of the title because the font color and
the “mask” on top of the caption bar are both white. And I’d just like to
know how to enable/disable it because I’ve seen that it can be done.
I thought of something myself (I’m probably way off…): implementing
DrvDitherColor and returning DCR_SOLID. I set the GCAPS_COLOR_DITHER flag
and changed DEVINFO’s cx/cyDither to something nonzero, which according to
the DDK docs is required if you want GDI to call the DrvDitherColor
callback. DrvDitherColor is never getting called once. Like I said this
solution was jut a wild guess.
Thanks in advance
“Tim Roberts” wrote:
CJ wrote:
>I have a mirror driver that’s using a device managed surface and punting
>back to EngXxx functions. Using a usermode process i’m also able to save
the
>buffer to a .bmp file and see the results. When the driver’s in 32/24 or
16
>bpp mode the .bmp of the buffer looks just fine. If I switch to 8bpp all
>caption bars drawn on my surface don’t show any banding, which is what
I’m
>expecting. (kinda what you see when you take a screenshot of your desktop
>and save it as an 8-bit bmp) Here’s an actual part of the .bmp created
using
>the contents of the buffer used for the surface in the mirror driver:
>http://img97.imageshack.us/img97/5665/gradient6pp.png
>
>
Banding sucks. You get that in the situation you described because the
bitmap mapping process does a simple “find closest color operation”.
However, when the actual drawing is done, it’s done using solid brushes
with various shades of color. When you draw on an 8-bit surface with a
solid brush that is not directly found in the palette, the drawing is
done using a technique called “dithering”. Dithering creates an 8-by-8
brush using a mix of the two palette colors that are closest to the
desired color. Dithering is a sophisticated process that produces much
better visual results than banding.
>Anybody know what’s going on here? I just want it to draw the caption
bars
>“normally” in 8 bpp mode, so it shows banding instead of this pixel
pattern.
>
>
Why do you think the banding is “normal”? If you change your desktop to
an 8-bit mode, you’ll see exactly that same dithering in the caption
bars. Seriously, dithering=good, banding=bad.
>Just another quick question: The DDK example mirror driver shows setting
the
>GCAPS_PALMANAGED flag when in 8 bpp mode. I removed this flag because it
>would cause all caption bars on the primary display to be drawn using a
>solid color. Microsoft’s Netmeeting mirror driver also causes this to
>happen. Should mirror drivers be using GCAPS_PALMANAGED at all?
>
>
Do you expect to support palettes in your mirror driver?
It’s interesting to me that graphics displays have come so far in the
last decade that dithering and palette management is no longer
recognized. Ten years ago, virtually every display was 8 bit, and
dithering was something that display drivers knew intimately.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
----- Original Message -----
From: “CJ” Newsgroups: ntdev To: “Windows System Software Devs Interest List” Sent: Saturday, May 27, 2006 9:10 PM Subject: [ntdev] Mirror driver 8bpp gradient problem
> Hi, > > I have a mirror driver that’s using a device managed surface and punting > back to EngXxx functions. Using a usermode process i’m also able to save the > buffer to a .bmp file and see the results. When the driver’s in 32/24 or 16 > bpp mode the .bmp of the buffer looks just fine. If I switch to 8bpp all > caption bars drawn on my surface don’t show any banding, which is what I’m > expecting. (kinda what you see when you take a screenshot of your desktop > and save it as an 8-bit bmp) Here’s an actual part of the .bmp created using > the contents of the buffer used for the surface in the mirror driver: > http://img97.imageshack.us/img97/5665/gradient6pp.png > > Instead it’s drawing a sort of mask on top of every caption bar. The palette > I’m using in 8 bit mode is the same as used in the perm2/3 examples (the 20 > static colors and 236 other colors generated using a simple loop). Other > parts of the screen look like they are supposed to, it only happens for > caption bars. I stumbled across this sentence in the DDK “The Windows 2000 > (and later) Shell uses gradient fills on all caption bars.” On that same > page it also says “For an 8-bpp surface, GDI does not call the driver’s > DrvGradientFill function.” I hooked DrvGradientFill anyway, but as expected > it never got called once. > > Anybody know what’s going on here? I just want it to draw the caption bars > “normally” in 8 bpp mode, so it shows banding instead of this pixel pattern. > Just another quick question: The DDK example mirror driver shows setting the > GCAPS_PALMANAGED flag when in 8 bpp mode. I removed this flag because it > would cause all caption bars on the primary display to be drawn using a > solid color. Microsoft’s Netmeeting mirror driver also causes this to > happen. Should mirror drivers be using GCAPS_PALMANAGED at all? > > Thanks in advance > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Yes… this is related to dithering. Since my attempt described in my
previous post failed to disable dithering… can somebody point me in the
right direction on how todo this (in a mirror driver that is)?
DrvDitherColor is never getting called so I can’t return DCR_SOLID. (if
that’s the way to disable dithering at all)
Thanks
“Maxim S. Shatskih” wrote
Maybe this relates to color dithering in some way?
Yes… this is related to dithering. Since my attempt described in my
previous post failed to disable dithering… can somebody point me in the
right direction on how todo this (in a mirror driver that is)?
DrvDitherColor is never getting called so I can’t return DCR_SOLID. (if
that’s the way to disable dithering at all)
So, what do you get when the title bar is drawn? Do you get a DrvBitBlt
call with a pre-made brush that didn’t come from your mirror driver?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Yes… this is related to dithering. Since my attempt described in my
>previous post failed to disable dithering… can somebody point me in the
>right direction on how todo this (in a mirror driver that is)?
>DrvDitherColor is never getting called so I can’t return DCR_SOLID. (if
>that’s the way to disable dithering at all)
>
>
So, what do you get when the title bar is drawn? Do you get a DrvBitBlt
call with a pre-made brush that didn’t come from your mirror driver?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>CJ wrote:
>
>
>
>>Yes… this is related to dithering. Since my attempt described in my
>>previous post failed to disable dithering… can somebody point me in the
>>right direction on how todo this (in a mirror driver that is)?
>>DrvDitherColor is never getting called so I can’t return DCR_SOLID. (if
>>that’s the way to disable dithering at all)
>>
>>
>So, what do you get when the title bar is drawn? Do you get a DrvBitBlt
>call with a pre-made brush that didn’t come from your mirror driver?
>
>
Does your DrvRealizeBrush get called? That would be one place to
“interfere”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
DrvRealizeBrush only gets called when I call BRUSHOBJ_pvGetRbrush myself.
According to the DDK docs one should call this function if the iSolidColor
member of the BRUSHOBJ structure is 0xFFFFFFFF and the pvRbrush memeber is
NULL. So that’s what I’m doing in DrvBitBlt. I’m not sure what todo in
DrvRealizeBrush though… other than calling BRUSHOBJ_pvAllocRbrush. Which
in turn reserves memory to store information for the driver’s realization of
the specified brush. But as far as I can see I don’t have to store any
specific information since I’m not actually drawing anything myself. I just
want to be able to set a solid, nearest color (instead of dithering) but
right now I don’t see how I could do that inside DrvRealizeBrush. Any ideas?
Thanks in advance
“Tim Roberts” wrote
CJ wrote:
>Yes, that’s exactly what’s happening.
>
>“Tim Roberts” wrote
>
>
>>CJ wrote:
>>
>>
>>
>>>Yes… this is related to dithering. Since my attempt described in my
>>>previous post failed to disable dithering… can somebody point me in
the
>>>right direction on how todo this (in a mirror driver that is)?
>>>DrvDitherColor is never getting called so I can’t return DCR_SOLID. (if
>>>that’s the way to disable dithering at all)
>>>
>>>
>>So, what do you get when the title bar is drawn? Do you get a DrvBitBlt
>>call with a pre-made brush that didn’t come from your mirror driver?
>>
>>
Does your DrvRealizeBrush get called? That would be one place to
“interfere”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I messed around with the mirror driver for a bit again. It doesn’t look like
DrvRealizeBrush is where I can modify the brush GDI is gonna use to draw. I
can allocate memory for a brush, but I don’t have anything to store in that
memory since I don’t do any of the drawing myself, I just punt back. I just
want it to use the nearest color in the palette I provided instead of
dithering. It looks like the only call left is DrvDitherColor, and the
return DCR_SOLID.
The problem I’m facing right now is that my DrvDitherColor is never getting
called. I wonder if this is even possible in a mirror driver (the DDK docs
only state that mirror drivers can support the realization of brushes). So
does anybody know if it’s even possible to make GDI call DrvDitehrColor in a
mirror driver. Or better yet, point me in the right direction on how to
disable color dithering.
