roVideoPlayer & transparency

The AlphaEnable setting only comes into play when you draw to the screen or bitmap. It determines whether what you're drawing to it alpha blends or not. With it disabled, the pixels of the object you're drawing replace the pixels on the screen/bitmap. With it enabled, they blend together. So, unless you have a need to overlay multiple bitmaps over the same area of the screen, you probably always want AlphaEnable set to False on the screen when using it with the roVideoPlayer. If you do need to overlay multiple bitmaps in the same area of the screen, then you may have better luck blending them to a separate bitmap first, then drawing that to the screen.

Thank you endless. I was aware of how it works but could not make it
Work with a type of effect I had developed. It is in fact a complex sprite
With a number of regions overlayed on top of each other. All the regions
Are animating together at different speeds but the top layer sprite has
Regions that expose transparent sections of the bitmap. So this would
Fall into the category you have pointed out. However, given that these
Complex sprites work quite well with every other component in the
Channel except the rovideoplayer along with the kludgy way needed
To expose the videoplayer In the first place, I feel that this is a design
And implementation flaw in the SDK itself. As a matter of fact when I
First tried to expose a videoplayer in an imagecanvas a few months ago
The documentation instructed you to put it in its own layer. I spent all
Day trying to figure out how to do this. You can't just stick it in a layer
You can't setlayer to it, finally I looked at the example to see where
Setlayer was called for the player. Never did find it. But did find
An uncommented layer with a rectangle drawn transparently and
Figured it out. So I remain frustrated with the videoplayers implementation
And it looks more like a hack job than a thought out design

The video plane is "below" (lower z-order) than the graphics plane. This is a feature of the hardware in all products. The video plane therefore has hardware constraints, so you can't for example, have two video planes or stack a video plane on top of graphics.

--Mark

If you look at the example that I submitted
In the roscreen thread I do exactly what you
Say I cannot do : I put a graphic behind
The video player! The composite z order
Allows you to specify a z order. The image canvas
Layer allows you to specify a layer. And it does
Work. What does not work in all circumstances
Is the method of displaying the player.
This method is in direct conflict with the
Rest of the API

If that's what your code was really doing, there would be something that associates the roVideoPlayer with a sprite or a z-order. But there's isn't; the only place you use m.VP is to set the destination rectangle. The video plane is always behind the graphics plane. The only reason it looks like it's in front of graphics is because it's showing through the transparent hole you've punched in the graphics plane.

An roScreen and everything that's drawn to it, either directly or via roCompositor, is drawn on the graphics plane. The sprite z-order just determines the temporal order that sprites are drawn; lower z-orders are drawn first. In fact all screen types except the video player (with the complicated exception of roGridScreen) are drawn to the graphics plane. The only reason video is ever visible is when there is transparency in the graphics plane to reveal part or all of the video plane. This is why video display works the way it does.

--Mark

HI Mark
Thanks for your input. You are very helpful on this board.

I am speaking in terms of the API. I realize now that my mildly cynical frustration above may have been somewhat misleading
My questions and answers related to my posts are strictly in terms and terminologies of the interface that I am using.
As far as what happens beneath the wrapper should for the most part be insulated from the programmer with the exception
of general design rules set forth in the documentation. What I mean is that if the API uses terms like SetLayer, or SetZ then
I should be able to express myself in the same way. Even the roVideoScreen documentation follows exactly what I am talking about:

The roVideoPlayer can be used in conjunction with the roImageCanvas to do graphical overlays, windowed video, zoom, and programmatic control of playlists and trick play. When using with the roImageCanvas, you can put the roVideoPlayer is at a lower z-order layer than other imageCanvas layers and implement overlays on top of the playing video

As you can see the documentation uses the same terminology. I know where the videoplayer sits and I also know that the layered effect is a matter
of cropping. I also have a good idea of what goes on even further below these layers. Been in the business a long, long time.

My real problem here is that at times, I combine graphical animation and video playback. Being forced to keep the windows AlphaEnable flag set to false has created
a real problem for me. I can either show the animation or the videoplayer - not both; thus my frustration. I have tried many ways to get around this with no results
Even briefly changing it for drawing purposes only does not seem to make a difference
I feel that the videoplayer should have been integrated more seamlessly, even if it needed to be wrapped in or took as a parameter additional interface which
would free it from the windows alpha enable setting. It is simply a matter of alpha bit manipulation as you know. Even with this I should be able to use the alphaenable
settings of bitmaps to create the hole. And I can - just not over the videoplayer with the windows alpha enable set to true. So I still ask "Am I missing something here" ? I am beginning to think not for even the documentation is not sure how alpha blending works in all cases:

There are limitations when using the onscreen bitmap as a source. For example, Alpha blending may not work. (ed. we need to verify this)

Anyway I appreciate your help. I have a couple of ideas I want to try then I'll take it from there