On Fri, Nov 14, 2003 at 05:39:26PM +0800, Selwyn Tang wrote: > On 11/14/2003 04:46 PM, Ville Syrj�l� wrote: > > Set the buffermode to backvideo. > > Thanks! This eliminates the flickering. What's interesting is that in > df_window.c, it first checks the card caps for alphachannel and > coloralpha. If either one is unavailable, it sets buffermode to > backsystem. Else, it use the default mode, which is, in my case, > frontonly. For my cle266, both alphachannel and coloralpha are available > for both layers (primary and cle266 overlay), so it uses the default > frontonly. The flickering only occurs on the overlay, but not the primary. > > I don't understand why it uses backsystem when either alpha things is > unavailabe.
Because reading from video ram is very slow. If the card can't do the alpha blending the CPU will have to do it. > > YUV support is probably the number one reason for using overlays. Another > > good reason is hw scaling. > > AFAIK, there are two video input ports (VIP) and one bt.656 on cle266. > So I guess the overlay is for these video capture stuffs. You can probably set the capture and overlay windows to the same address so you see the captured data. This is exactly what the marvel drivers do on matrox cards. But I think this behaviour is just wrong and the capture driver should not even know about the overlay. > If so, I think > I should just keep using the primary layer only, since when I get the > overlay layer, it just blanks out the screen and doesn't seem to be > alpha blended with the primary layer. What do you think? That's a matter of setting the layer options. But I don't think the cle266 driver currently implements those options correctly. And as we've discussed on directfb-dev cle266 handles per pixel alpha in a very odd way so it's not very useful. -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-users" as subject.
