Louis
Wed Apr 16 10:54:19 PDT 2008
For the Offscreen System Surfaces, typically just calling
DDGPECreateSurface/DDGPECanCreateSurface when DDSCAPS_SYSTEMMEM is set will
work (you've probably already figured this out, but others might have the
same issue).
The blt issue could be related to Lock behavior. The (0, 0) indicates where
the check is failing relative to the locked surface. The call to Lock is
using the same rect that was used to blt, so Lock should be returning an
offset into the surface based on that rect.
If you put a breakpoint in the verification routing that's failing, you
should be able to determine if either Blt is incorrectly adjusting the
destination rect (the destination rect is relative to the display, not the
current window) or if Lock is incorrectly returning an unadjusted surface
pointer.
After doing the Blt, you should see the colored square in the upper left
corner of the current window. If it's offset relative to the current window,
your Blt is probably using incorrect rectangles, and if it's in the exact
upper left corner your Lock is probably not offsetting the surface pointer
correctly.
--
Louis Clausen
Software Design Engineer in Test
Windows Devices Core Multimedia
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
"ABatWork" <ABatWork@discussions.microsoft.com> wrote in message
news:FC532C49-EEE4-427F-8BCB-843906194C76@microsoft.com...
> Hi Louis,
>
> On further working on the issue. I found something something suspious in
> test ID 102.
>
> this test check the value of pixel at (0,0) on both primary as well as
> offscreen surface. However in DrvAnyBlt->AnyBlt->ClipBlt->FillRect, we get
> destination cordinates as (1, 24, 11, 34), which should be ideal one. So
> Blt
> happens at above destination surf coordinate only.
>
> Since CETK test case checks pixel value at the wrong place, Its obvious to
> see pixel value mismatch failure.
>
> For confirmation, I tried changing value of destination rect cordinate to
> (0,0,10,10) in debug watch window, and the test started passing.
>
> Is this a CETK bug, or something wrong in ddi.
>
> Can someone please through some light on the issue..
>
> Thanks in advance for help.
>
>
> "ABatWork" wrote:
>
>> Hi Louis,
>>
>> On further working on the issue. I was able to remove 2 kind of failure
>> as
>> mentioned in my last reply.
>>
>> Now Only failure message I am getting is as follows:
>> "After Blt, found unexpected colors at (0, 0)."
>>
>> eg. in case of offscreen surface in system memory(RGB 565) messages on
>> the
>> debug shell is as follows(after enabling debug zones):
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> Verifying Surface Creation Behavior of surface: Offscreen surface in
>> system
>> memory - (RGB 565)
>> Surface Created! Verifying proper Blt behavior
>> Verifying Colorfill to Test Surface
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xf0f0) rclTrg=t:0,l:0,b:480,r:800
>> ClipBlt continue phase
>> EmulatedBltFill16
>> Leaving DrvBitBlt
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xf0f0) rclTrg=t:24,l:1,b:34,r:11
>> ClipBlt continue phase
>> EmulatedBltFill16
>> Leaving DrvBitBlt
>> Verifying Blt from Test surface to Primary surface
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xcccc) rclTrg=t:24,l:1,b:34,r:11
>> XO_TRIVIAL
>> ClipBlt continue phase
>> Leaving DrvBitBlt
>> ### After Blt, found unexpected colors at (0, 0). Expected (31, 31, 0, 0)
>> but found (7, 27, 20, 0) (RGBA)
>> Verifying Blt from Primary surface to Test surface
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xf0f0) rclTrg=t:0,l:0,b:480,r:800
>> ClipBlt continue phase
>> EmulatedBltFill16
>> Leaving DrvBitBlt
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xf0f0) rclTrg=t:24,l:1,b:34,r:11
>> ClipBlt continue phase
>> EmulatedBltFill16
>> Leaving DrvBitBlt
>> Entering DrvAnyBlt
>> AnyBlt (rop4 = 0xcccc) rclTrg=t:24,l:1,b:34,r:11
>> XO_TRIVIAL
>> ClipBlt continue phase
>> Leaving DrvBitBlt
>> ### After Blt, found unexpected colors at (0, 0). Expected (31, 31, 0, 0)
>> but found (0, 32, 31, 0) (RGBA)
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> I am using EmulatedBlt from GPE. Also All the DDraw tests except test ID
>> 102
>> are passing.
>> I tried to debug the issue a lot, but couldn't reach to any failure
>> point.
>> Can you please provide me some pointers for further debugging on the
>> issue.
>>
>> Let me know if you need some more information from my side.
>>
>> Thanks for help in advance.
>>
>> Regards
>> Amit Bansal
>>
>>
>>
>>
>>
>>
>>
>> "ABatWork" wrote:
>>
>> > Hi Louis,
>> >
>> > Thanks for reply!
>> >
>> > From the log, if only focus on messages followed by "###", then two
>> > types
>> > of failure broadly came into the picture:
>> > 1) Mismatch between expected color and found color while blting from
>> > test
>> > surface to primary surface and vice versa.
>> > 2) failure in creating offscreen surface in system memory.(It comes for
>> > RGB88, RGB0888, ARGB888 formats)
>> >
>> > Is first types of messages are not important?
>> >
>> > Also Is it compulsary to support offscreen surface in system memory for
>> > all
>> > of the above formats, even if we don't support them.
>> >
>> > Thanks
>> >
>> >
>> >
>> > "Louis Clausen [MS]" wrote:
>> >
>> > > To help diagnose this problem, it would be helpful to see what the
>> > > log
>> > > contains. There should be a failure message preceded by '###' at any
>> > > point
>> > > in the log where a failure is being returned. Also, what is the test
>> > > result?
>> > >
>> > > Please note that this test will attempt to create surfaces in each
>> > > possible
>> > > format; it is normal for a typical driver to not be able to create
>> > > many of
>> > > these surfaces. If the surface needs to be supported, you should get
>> > > a
>> > > message preceded by '###'. The message "Could not create surface,
>> > > continuing" indicates that the surface type is unsupported by the
>> > > driver and
>> > > that this is not an issue.
>> > >
>> > > --
>> > > Louis Clausen
>> > > Software Design Engineer in Test
>> > > Windows Devices Core Multimedia
>> > >
>> > > This posting is provided "AS IS" with no warranties, and confers no
>> > > rights.
>> > > You assume all risk for your use.
>> > >
>> > > "ABatWork" <ABatWork@discussions.microsoft.com> wrote in message
>> > > news:7EFD4F34-97F7-4112-BA59-594ADB1EFD94@microsoft.com...
>> > > > While running Ddraw CETK test cases, we get failure in ddraw test
>> > > > case 102
>> > > > under Wince 6.0 enviorment.
>> > > >
>> > > > DDraw surface creation is failing only for some of the formats, for
>> > > > rest
>> > > > its
>> > > > working.
>> > > > Some of Format under which Ddraw surface creation failes, are as
>> > > > follows:
>> > > >
>> > > > Overlay surface in video memory - (YUV NV12)
>> > > > Overlay surface in video memory - (YUV I420)
>> > > > Overlay surface in video memory - (YUV YUY2)
>> > > >
>> > > > Overlay surface in system memory - (Unspecified Pixel Format)
>> > > > Overlay surface in system memory - (256 color palette)
>> > > > Overlay surface in system memory - (RGB 555)
>> > > > Overlay surface in system memory - (RGB 565)
>> > > >
>> > > > CETK gives only one messges for all of these kind of messages
>> > > >
>> > > > "GWES Hook fails surface creation. IDirectDraw::CreateSurface
>> > > > fails.
>> > > > Could not create surface, continuing"
>> > > >
>> > > > Any idea what are above formats, and what do i need to do in order
>> > > > to
>> > > > provide support for it..
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >