I think in this way too.
But I don’t get (under debbuger)
DrvBitBlt/DrvAlphaBlend/DrvStretchBlt/DrvStretchBltROP/DrvTransparentBlt
when I move cursor to the start button. I only get DrvCopyBits. 
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> Could any could say what exactly Drv graphical function are using to draw
>> Start menu button?
>> I only see that when I move cursor to the button, DrvCopyBits occurs
>> which only copy the pixels, so I can get changed rectangle from it, but I
>> can’t get only pixels which were modified from this function, so I assume
>> that these is another diffrent Drv function call before DrvCopyBits, but
>> I can’t understand which.
>
> My assumption is that Explorer contains three separate bitmaps: one with
> the button up, one with the button down, and one with the button’s “hover”
> state. When you bring the mouse over the button, it just copies the
> “hover” bitmap image to replace the entire button area. Thus, the
> “changed rectangle” is the entire button.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
User5 wrote:
I think in this way too.
But I don’t get (under debbuger)
DrvBitBlt/DrvAlphaBlend/DrvStretchBlt/DrvStretchBltROP/DrvTransparentBlt
when I move cursor to the start button. I only get DrvCopyBits.
Right. Why is that a surprise? It’s copying the whole “start” bitmap
to the screen – no blending, no ROPs, just a straight copy. That’s
exactly one DrvCopyBits call.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Because driver doesn’t copy bitmap as rectangle.
Take a look at this picture
http://img291.imageshack.us/img291/1027/notalltj9.png
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> I think in this way too.
>> But I don’t get (under debbuger)
>> DrvBitBlt/DrvAlphaBlend/DrvStretchBlt/DrvStretchBltROP/DrvTransparentBlt
>> when I move cursor to the start button. I only get DrvCopyBits.
>>
>
> Right. Why is that a surprise? It’s copying the whole “start” bitmap to
> the screen – no blending, no ROPs, just a straight copy. That’s exactly
> one DrvCopyBits call.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
I don’t maybe I did something wrong.
But when I track only DrvCopyBits and I press for example on shortcut, I get
a rectangle on icon with empty(not modified) small rectangle 32x32 inside
it. And when I move cursor to the start menu button I only get one
rectangle. (without clipping).
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> I think in this way too.
>> But I don’t get (under debbuger)
>> DrvBitBlt/DrvAlphaBlend/DrvStretchBlt/DrvStretchBltROP/DrvTransparentBlt
>> when I move cursor to the start button. I only get DrvCopyBits.
>>
>
> Right. Why is that a surprise? It’s copying the whole “start” bitmap to
> the screen – no blending, no ROPs, just a straight copy. That’s exactly
> one DrvCopyBits call.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
I’ve found bug in my code.
Now If I click on the icon, from DrvCopyBits I get only one rectangle around
icon, but from DrvBitBlt/DrvAlphaBlend I get only the pixels which are
modified, so I want exclude DrvCopyBits tracking, but I can’t do this
because for example start menu button is only rendering with DrvCopyBits as
I see.
“User5” wrote in message news:xxxxx@ntdev…
>I don’t maybe I did something wrong.
> But when I track only DrvCopyBits and I press for example on shortcut, I
> get a rectangle on icon with empty(not modified) small rectangle 32x32
> inside it. And when I move cursor to the start menu button I only get one
> rectangle. (without clipping).
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
User5 wrote:
I’ve found bug in my code.
Now If I click on the icon, from DrvCopyBits I get only one rectangle around
icon, but from DrvBitBlt/DrvAlphaBlend I get only the pixels which are
modified, so I want exclude DrvCopyBits tracking, but I can’t do this
because for example start menu button is only rendering with DrvCopyBits as
I see.
I’m not sure I understand the question. Are you saying that you don’t
want to have to handle DrvCopyBits? I’m sorry, but you can’t avoid
that. DrvCopyBits support is required.
Now, I would point out that DrvCopyBits is a regular subset of
DrvBitBlt, so it is trivial to have DrvCopyBits call into DrvBitBlt to
do the work. You can figure out which parameters you need and which can
be null.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry If saying something wrong.
I mean not to remove DrvCopyBits from driver, but not to calculate changed
pixels from it, because from parameters that I get inside this function I
only get rectangle(-s) which covers the pixels which not always are being
modified(these rectangles I get form prclDst and pco).
I assume, that when driver copy pixels (bits) from one location to another,
there are another functions involved in this process.
For icons it’s DrvBitBlt/DrvAlphaBlend , but I can’t find functions which
uses to draw start menu button.
So I would like to know, does the driver use any other functions to draw
start menu button except for DrvCopyBits?
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> I’ve found bug in my code.
>> Now If I click on the icon, from DrvCopyBits I get only one rectangle
>> around icon, but from DrvBitBlt/DrvAlphaBlend I get only the pixels which
>> are modified, so I want exclude DrvCopyBits tracking, but I can’t do this
>> because for example start menu button is only rendering with DrvCopyBits
>> as I see.
>>
>
> I’m not sure I understand the question. Are you saying that you don’t
> want to have to handle DrvCopyBits? I’m sorry, but you can’t avoid that.
> DrvCopyBits support is required.
>
> Now, I would point out that DrvCopyBits is a regular subset of DrvBitBlt,
> so it is trivial to have DrvCopyBits call into DrvBitBlt to do the work.
> You can figure out which parameters you need and which can be null.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
User5 wrote:
I mean not to remove DrvCopyBits from driver, but not to calculate changed
pixels from it, because from parameters that I get inside this function I
only get rectangle(-s) which covers the pixels which not always are being
modified(these rectangles I get form prclDst and pco).
What makes you think that? If DrvCopyBits is called with the drawing
surface as the destination, then every pixel in the destination
rectangle will be touched. Some of them might be the same as what was
already there, but you wouldn’t know that.
I assume, that when driver copy pixels (bits) from one location to another,
there are another functions involved in this process.
For icons it’s DrvBitBlt/DrvAlphaBlend , but I can’t find functions which
uses to draw start menu button.
I thought you said DrvCopyBits was drawing the start menu button?
Now, it is possible that GDI is using DrvCopyBits to read a copy of the
previous bits, updating them as an in-memory bitmap, and then putting
them back on your display with DrvCopyBits.
So I would like to know, does the driver use any other functions to draw
start menu button except for DrvCopyBits?
If you are watching the calls you get, then YOU are in a position to
answer this.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Now, it is possible that GDI is using DrvCopyBits to read a copy of the
previous bits, updating them as an in-memory bitmap, and then putting
them back on your display with DrvCopyBits.
I think this is how most ROPs are implemented in EngBitBlt for the non-standard
format device surface.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com