Asif,
Yes, I think that makes sense. Technically, you should just flip the
surface at that point, and then do the “displaying” in the vsync, but I
suspect you can’t do that with your hardware. Our hardware has
double-buffering, so we change the register at any point, but it doesn’t
actually change the output on screen until the next vsync.
When it comes to sourceColorKeying, you really will need to think about
what this means: You’re supposed to compare the main plane for colour, and
when the colour is a match, you draw the pixel for the overlay, otherwise
the main plane. This is very difficult to do in software (well, it’s TIME
CONSUMING, it’s not rocket science if you don’t mind it being a bit slow).
As I suggested last time, you could use a ‘cheat’ method where you keep
track of rectangles on the main plane. Say we have a 1024 x 768 screen, and
currently we have a rectangle of (200, 200) - (400, 600) that is our DVD
display. At this time, the whole area is coloured with the KEY. As long as
nothing draws in this section of the screenn, you don’t need to do anything
other than update the whole area when DdFlip is called.
Now, some software decides to draw a square at (300, 300) - (400, 400). So
your code in BitBlt (or whatever draws the square) will say “Aha, it’s
within my overlay section, lets figure out what regions are still correct
colour”. So, you will end up with a new list of rectangles: 200, 200 - 300,
600; 300, 200 - 300, 400; 300, 400 - 400, 600 (or something like that).
Now, you can blit this list of rectangles to the screen. If you get a shape
that isn’t a rectangle, split it into big rectanles first, then take any
small odd-shaped bits and mark them as “software handled”, and use a
compare and copy type routine, where you compare the pixel with the
keycolour and copy the correct pixel accordingly. This should be possible
to do with a pretty small loop, perhaps even using advanced MMX or SSE
instructions if necessary.
–
Mats
xxxxx@lists.osr.com wrote on 02/04/2005 02:25:32 PM:
A-O-A,
Thanks for all these responses. I have written a display driver and
currently writing code for giving Overlay support. I have allocated Host
Memory for OVerlay Surface. Actually my objective is to play WinDVD on my
display. Well finally my DdUpdateOVerlay functions is being called with
Show
Flag. Actually I am doing overlay copying to the primary surface in
software. But I don’t know when to copy it. I mean I don’t know about the
function called by the DirectDriver for telling the driver to copy(paste)
the OVerlay on the screen. What I have done is, I am copying it in DdFlip
function. Whenever WinDVD is played, DdUpdateOverlay is called for two
times
and then DdLock and DdFlip functions are being called continously unless
you
change the position of the DVD. IN that case DdUpdateOVerlay is called.
So I
think DdFlip is the right function. I have also exported DdBlt function,
but
it is not being called. Can any one give idea about that.
Also I don’t have the procedure of pasting overlay to target surface
using
sourceColorKeying. Please help me in this regard.
Regards,
Asif
Subject: Re: local memory for overlay support
From: Mats PETERSSON
> Date: Mon, 31 Jan 2005 13:39:27 +0000
> X-Message-Number: 10
>
>
>
> Ok, let’s first see if I understand what you want to do:
> You want to allocate a chunk of host memory (such as EngAllocMemory or
> KeAllocatePoolWithTag) and use this memory to store the image for the
> overlay.
>
> I don’t see a problem with this, as such. I would have thought that
> allocating video memory would be preferrable from a performance
standpoint,
> as you don’t have to copy the memory three times then.
>
> The problem comes when trying to combine the image from the overlay and
the
> main channel. The overlay is normally “colour-keyed”, which means that
when
> the main channel contains a certain colour, you should replace it with
the
> contents of the overlay. If it’s any other colour, it should be the main
> channels content. I don’t know if there’s a function in your graphics
chip
> that can “copy these pixels to the destination if the destination is this
> colour”. If you do that by software, it will most likely be PAINFULLY
slow.
> Of course, for video-playback, the main channel’s overlay area will most
> likely be rectangular and constant, so you could track any changes to the
> main plane area and just see if anyone puts anything else in the area
(such
> as tool-bars and menus or overlapping with other apps), using rectangular
> clipping to make the copy straight-forward. Then it will only be slow
when
> something has changed in that area, which is most likely NOT when the
user
> is watching the DVD itself…
>
> I hope this helps.
>
> [To our nomenclature, “Local memory” means memory that is connected to
the
> graphics chip, and “Host memory” is the computers “main memory”. I’m not
> sure if this is what everyone else in the world of graphics call the
> different types of memory…]
>
> –
> Mats
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT0000C266