Re: Xvideo: Autopaint colorkey bug in the Unix version of Helix

Thanks for all the helpful responses that I received so far.

>> Unfortunately, Xv attributes are system-global resources (think 
>> "global variable") that can be changed outside of an application at 
>> anytime, requiring application to be color-key-aware to work 
>> correctly, even without benefiting from color key feature.
>> <snip>
>
> Only one application, system wide, can have access to XVideo at a time.
> Actually, even within one application (RP for example) we can only have
> one overlay. That is, if we have two videos playing only one can have
> the overlay (XVideo port open) and the other has to be using the normal
> XPutImage RGB stuff (or XShmPutImage). Basically, only one *thing* can
> have access to the hardware in that fashion.

>> For even more robust implementation, is there such a case where a 
>> video driver/adapter supports two ports and two application playback 
>> videos at the same time while each setting the XV_AUTOPAINT_COLORKEY 
>> attribute to different values (race condition)? Is the attribute 
>> private per-port or global per driver/adapter?
>
> No, see above. Well, this is true for the way we use it. If you want to
> talk about 'textures' then this is not true. Also, it could be in the 
> last
> year or so support was added for multiple overlays, but it has never 
> happened
> on windows and our site does not support more then one.
>
> I would really like to get rid of overlays all together and start using
> textures or something equivalent. OpenGL would be a good replacement I
> think...... 

> Theoretically it is possible to have more than 1 video port.
> The attributes are port/video specific and it is application's
> responsibility to obtain the required lock before setting a port
> attribute.
> XLockDisplay() I think.
>   

XLockDisplay() is probably a lock on just one X client's connection 
opened within an application against multiple threads. It probably 
doesn't lock the X Server or its resources/extensions.

I suppose you meant XvGrabPort().

Now, I started a video playback with overlay enabled. Then, I set 
XV_AUTOPAINT_COLORKEY using xvattr utility, while the video is still 
playing back.

There was no error reported and xvattr managed to change the value of 
XV_AUTOPAINT_COLORKEY. The resulting effect took place (more or less) 
immediately -- when switching window focus, Xv apparently draw or not 
draw the colorkey (depending on the current setting) and impacting the 
video displayed.

Helix does use XvGrabPort().  However, that apparently isn't sufficient 
to secure exclusive use against change of Xv properties.

Maybe handling this case through the use of XvPortNotify() is necessary?

Anyway, that is just an observation. With the 310Atlas branch not using 
XV_AUTOPAINT_COLORKEY anymore, it is not impacted by this issue -- 
regardless the current modified setting, the application always paints 
the color key and it always works.

Thanks.

-- 
Daniel Yek.



Greg Wright wrote:
> Daniel Yek wrote:
>>
>> Greg Wright wrote:
>>> Daniel, take a look at:
>>
>> OK, I hadn't read this response and had yet to start looking deeper 
>> into the code when I commented with my own understanding.
>>
>>>     m_bNeedColorKeyFilled = FALSE;
>>> ...
>>>     //XXXgfw Well, this turns out to be mostly true. With our new fancy
>>>     //presentation-feature SMIL demo we have a problem where the 
>>> video can not
>>>     //be seen until you see the player...
>>> ...
>>> It looks like we should be working even without Xv painting the
>>> color key for us. Is this change, in basesurf.cpp, in your branch?
>>
>> Nope, this change is not in 150Cay. I'll merge it over.
>
> that may not be the only change associated with that fix. Be sure
> to check CVS logs, or something, to see if anything else was
> checked in to other site files.
>
>>>
>>>  ColorKey=0x00
>>>
>>> Now launch RP and play a video, it should look OK. Bring up an xterm
>>> with a black background:
>>>
>>>   xterm -fg gold -bg black -sl 1000 -sb
>>>
>>> Move that xterm on top of the RP video. You will see the video 
>>> everywhere
>>> that the xterm has black; the background of the xterm. 
>>
>> Yes, that works. One just needs to pay attention to expose two edges 
>> of the video window so that blitting of the rectangular area happens.
>
> That depends on the driver as well, some don't seems to draw the video
> unless those conditions hold, others do.
>
> Back in the good old days, before KDE/GNOME started replacing the root
> window with their own thing, you could do this:
>
> xsetroot -solid black
>
> Then, add this to your RP prefs:
>
>   ColorKey=0x00
>   WallPaperMode=1
>   StretchToFill=1
>
> This would make the site use the root window of the display as
> the video output window, the color key is black, which is what
> you set the root window to. Then just launch RP/splay and play
> a movie. It would run as the backdrop to your whole desktop. Pretty
> cool. :-) Stretch to fill just fills up the whole window ignoring
> aspect ratio. Looks good for some content on the root window.
>
> You can have all sorts of fun with colorkeys.
>
>
> You might also have  a look at the below pref if you are playing
> with ATI cards. Not sure if they still support that ATOM or not.
>
>         //This is used on ATI cards for debugging. It tells the driver
>         //to paint the window with the color key before each blt, or not.
>         pPreferences->ReadPref("PaintClipList", pBuffer);
>         if (pBuffer)
>         {
>             m_bPaintClipList = (::atoi((const 
> char*)pBuffer->GetBuffer()) == 1);
>             HX_RELEASE(pBuffer);
>         }
>
> --greg.
>

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev