How to handle with IDirectDrawSurface::UpdateOverlayZOrder in display

Dear all,

I'm developing WinMobile 6.0 display driver with ddraw multiple
overlay surfaces support.
Now my display driver can overlay multiple surfaces on the primary
surface.
But I don't know how to determine their z order when they are
overlapped with each other.
According to MSDN, IDirectDrawSurface::UpdateOverlayZOrder is defined
in DDraw API layer,
but it doesn't explain clearly about which DDHAL callback function
will be called in display driver?

It confused me for a long time, and any comment or suggestion will be
very appreciated.
Thanks.

Sheetal
Tue Mar 25 00:27:00 PDT 2008

Hi,

As per the documentation, enabling DDCAPS_ZOVERLAYS should allow the usage
of UpdateOverlayZOrder from applications. (Though none of the sample drivers
have it enabled :)) But as you say - there is no callback function listed
there which could implement this at the driver level.

However, there is an element named dbnOverlayRoot in the
DDRAWI_DIRECTDRAW_GBL structure, which they document as "The root node of the
doubly linked list of overlay z orders." So - In all probability, DirectDraw
itself is handling this - since it is maintaining the linked list of z-orders
- Though I am not sure.

Did you try this ?
1. Enable DDCAPS_ZOVERLAYS at the driver
2. Call UpdateOverlayZOrder from the application and check the results.

Regards,
-Sheetal.

"Makaliu@gmail.com" wrote:

> Dear all,
>
> I'm developing WinMobile 6.0 display driver with ddraw multiple
> overlay surfaces support.
> Now my display driver can overlay multiple surfaces on the primary
> surface.
> But I don't know how to determine their z order when they are
> overlapped with each other.
> According to MSDN, IDirectDrawSurface::UpdateOverlayZOrder is defined
> in DDraw API layer,
> but it doesn't explain clearly about which DDHAL callback function
> will be called in display driver?
>
> It confused me for a long time, and any comment or suggestion will be
> very appreciated.
> Thanks.
>

Damon
Wed Mar 26 10:01:03 PDT 2008

<Makaliu@gmail.com> wrote in message
news:ef31d3ba-c5f0-4d11-90a6-640844ab19c6@c19g2000prf.googlegroups.com...
> According to MSDN, IDirectDrawSurface::UpdateOverlayZOrder is defined
> in DDraw API layer,
> but it doesn't explain clearly about which DDHAL callback function
> will be called in display driver?


I'm not experienced in this area, but it appears that DDraw handles the
ordering itself, and then calls LPDDHALSURFCB_UPDATEOVERLAY in the driver.
--
Damon Barry
Windows Embedded CE Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.

Danny
Wed Apr 09 16:06:00 PDT 2008

Damon, Sheetal,

You seem to be implying that UpdateOverlay can be used as a function for
compositing N surfaces, which is what would be needed to support the concept
of Z-ordering and comibing multiple overlay surfaces, but I don't see how
UpdateOverlay can achieve this. The function specifies a source and target
surface, and if the SHOW flag is set, the resultant combined surface will be
displayed. I don't see how there is a means for calling this function
multiple times to indicate to the display driver that multiple surfaces be
composited together and then displayed.

Any help in understanding this is appreciated.

Needless to say, there is a serious lack of information on this feature.

Thanks,
Danny

"Damon Barry [MSFT]" wrote:

> <Makaliu@gmail.com> wrote in message
> news:ef31d3ba-c5f0-4d11-90a6-640844ab19c6@c19g2000prf.googlegroups.com...
> > According to MSDN, IDirectDrawSurface::UpdateOverlayZOrder is defined
> > in DDraw API layer,
> > but it doesn't explain clearly about which DDHAL callback function
> > will be called in display driver?
>
>
> I'm not experienced in this area, but it appears that DDraw handles the
> ordering itself, and then calls LPDDHALSURFCB_UPDATEOVERLAY in the driver.
> --
> Damon Barry
> Windows Embedded CE Multimedia
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>

Damon
Thu Apr 10 10:34:39 PDT 2008

"Danny" <Danny@discussions.microsoft.com> wrote in message
news:791A1FD7-ACEE-4E8B-98BD-C4F7ABE709E2@microsoft.com...
> You seem to be implying that UpdateOverlay can be used as a function for
> compositing N surfaces, which is what would be needed to support the
> concept
> of Z-ordering and comibing multiple overlay surfaces, but I don't see how
> UpdateOverlay can achieve this. The function specifies a source and
> target
> surface, and if the SHOW flag is set, the resultant combined surface will
> be
> displayed. I don't see how there is a means for calling this function
> multiple times to indicate to the display driver that multiple surfaces be
> composited together and then displayed.

To composite N surfaces, you need N overlays (or at least N-1, plus the
primary surface). UpdateOverlay only configures the attributes of one
overlay surface, in relation to the primary. The source and destination
rectangles (not surfaces) specified in this function are for (1) determining
the aperature on the overlay and (2) determining the overlay's position
relative to the primary surface, respectively. Each overlay is positioned
relative to the primary using UpdateOverlay, and then stacked in relation to
other overlays using UpdateOverlayZOrder(). If you haven't already, check
out the documentation under
http://msdn2.microsoft.com/en-us/library/aa918464.aspx.

--
Damon Barry
Windows Embedded CE Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.

Danny
Thu Apr 10 14:16:00 PDT 2008

Damon,

I am looking at Z-ordering from the viewpoint of the display driver, and
trying to determine how to implement support for Z-ordering. The
DDHAL_UPDATEOVERLAYDATA structure includes both source and destination
surfaces (as well as rectangles), so we can understand the compositing
relationship between the two surfaces specified via the
DDHAL_UPDATEOVERLAYDATA structure. But how does the driver determine the
overall Z-order relationship of each overlay surface? How is this
information communicated?

Thanks,
Danny

"Damon Barry [MSFT]" wrote:

> "Danny" <Danny@discussions.microsoft.com> wrote in message
> news:791A1FD7-ACEE-4E8B-98BD-C4F7ABE709E2@microsoft.com...
> > You seem to be implying that UpdateOverlay can be used as a function for
> > compositing N surfaces, which is what would be needed to support the
> > concept
> > of Z-ordering and comibing multiple overlay surfaces, but I don't see how
> > UpdateOverlay can achieve this. The function specifies a source and
> > target
> > surface, and if the SHOW flag is set, the resultant combined surface will
> > be
> > displayed. I don't see how there is a means for calling this function
> > multiple times to indicate to the display driver that multiple surfaces be
> > composited together and then displayed.
>
> To composite N surfaces, you need N overlays (or at least N-1, plus the
> primary surface). UpdateOverlay only configures the attributes of one
> overlay surface, in relation to the primary. The source and destination
> rectangles (not surfaces) specified in this function are for (1) determining
> the aperature on the overlay and (2) determining the overlay's position
> relative to the primary surface, respectively. Each overlay is positioned
> relative to the primary using UpdateOverlay, and then stacked in relation to
> other overlays using UpdateOverlayZOrder(). If you haven't already, check
> out the documentation under
> http://msdn2.microsoft.com/en-us/library/aa918464.aspx.
>
> --
> Damon Barry
> Windows Embedded CE Multimedia
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>

Damon
Mon Apr 14 13:52:31 PDT 2008

"Danny" <Danny@discussions.microsoft.com> wrote in message
news:7C20A352-11EA-45EB-82B0-B99FF2F1DF7A@microsoft.com...
> I am looking at Z-ordering from the viewpoint of the display driver, and
> trying to determine how to implement support for Z-ordering. The
> DDHAL_UPDATEOVERLAYDATA structure includes both source and destination
> surfaces (as well as rectangles), so we can understand the compositing
> relationship between the two surfaces specified via the
> DDHAL_UPDATEOVERLAYDATA structure. But how does the driver determine the
> overall Z-order relationship of each overlay surface? How is this
> information communicated?

It doesn't appear to be well documented, but from what I can tell, whenever
DirectDraw calls your UpdateOverlay function, you should examine
lpuod->lpDD->pOverlays, and compare it against your own, internally-cached
z-order array. pOverlays is a member of the DDRAWI_DIRECTDRAW_GBL
structure, and it points to an array of 32 LPDDRAWI_DDRAWSURFACE_LCL
elements. Index 0 is the front-most overlay. If the passed in array is
different from your cached array, you know you need to update the z-order.

Depending on whether its an expensive operation for your driver, another
option is to update the z-order every time UpdateOverlay is called.

--
Damon Barry
Windows Embedded CE Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.

Danny
Tue Apr 15 11:07:03 PDT 2008

Thanks Damon, this is exactly the type of information I was looking for.

Danny

"Damon Barry [MSFT]" wrote:

> "Danny" <Danny@discussions.microsoft.com> wrote in message
> news:7C20A352-11EA-45EB-82B0-B99FF2F1DF7A@microsoft.com...
> > I am looking at Z-ordering from the viewpoint of the display driver, and
> > trying to determine how to implement support for Z-ordering. The
> > DDHAL_UPDATEOVERLAYDATA structure includes both source and destination
> > surfaces (as well as rectangles), so we can understand the compositing
> > relationship between the two surfaces specified via the
> > DDHAL_UPDATEOVERLAYDATA structure. But how does the driver determine the
> > overall Z-order relationship of each overlay surface? How is this
> > information communicated?
>
> It doesn't appear to be well documented, but from what I can tell, whenever
> DirectDraw calls your UpdateOverlay function, you should examine
> lpuod->lpDD->pOverlays, and compare it against your own, internally-cached
> z-order array. pOverlays is a member of the DDRAWI_DIRECTDRAW_GBL
> structure, and it points to an array of 32 LPDDRAWI_DDRAWSURFACE_LCL
> elements. Index 0 is the front-most overlay. If the passed in array is
> different from your cached array, you know you need to update the z-order.
>
> Depending on whether its an expensive operation for your driver, another
> option is to update the z-order every time UpdateOverlay is called.
>
> --
> Damon Barry
> Windows Embedded CE Multimedia
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>

Andy
Wed Jun 25 13:20:00 PDT 2008

Hi Danny,

I am implementing code to handle the OverlayZOrder in my Windows Mobile
display driver. Do you know a good application to test if my implementation
works.

Thanks,
Andy Le
Windows Mobiles Display Driver

"Danny" wrote:

> Thanks Damon, this is exactly the type of information I was looking for.
>
> Danny
>
> "Damon Barry [MSFT]" wrote:
>
> > "Danny" <Danny@discussions.microsoft.com> wrote in message
> > news:7C20A352-11EA-45EB-82B0-B99FF2F1DF7A@microsoft.com...
> > > I am looking at Z-ordering from the viewpoint of the display driver, and
> > > trying to determine how to implement support for Z-ordering. The
> > > DDHAL_UPDATEOVERLAYDATA structure includes both source and destination
> > > surfaces (as well as rectangles), so we can understand the compositing
> > > relationship between the two surfaces specified via the
> > > DDHAL_UPDATEOVERLAYDATA structure. But how does the driver determine the
> > > overall Z-order relationship of each overlay surface? How is this
> > > information communicated?
> >
> > It doesn't appear to be well documented, but from what I can tell, whenever
> > DirectDraw calls your UpdateOverlay function, you should examine
> > lpuod->lpDD->pOverlays, and compare it against your own, internally-cached
> > z-order array. pOverlays is a member of the DDRAWI_DIRECTDRAW_GBL
> > structure, and it points to an array of 32 LPDDRAWI_DDRAWSURFACE_LCL
> > elements. Index 0 is the front-most overlay. If the passed in array is
> > different from your cached array, you know you need to update the z-order.
> >
> > Depending on whether its an expensive operation for your driver, another
> > option is to update the z-order every time UpdateOverlay is called.
> >
> > --
> > Damon Barry
> > Windows Embedded CE Multimedia
> >
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> >