On Tue, Nov 15, 2005 at 10:30:09PM +0100, Stefan Lucke wrote:
> On Dienstag, 15. November 2005 21:34, Mark Adams wrote:
> > > I guess that the changes to unichrome/uc_overlay.c will break
> > > softdevice. For VIA I have currently the following special code:
> > >
> > >          if (isVIAUnichrome)
> > >            videoLayer->SetLevel(1);
> > 
> > You could be right.  I assume softdevice wants the primary layer on top?
> > 
> 
> I want the video layer alpha blended with surface from primary layer.
> OSD is drawn on that. 

So you want the primary layer on top.

> > Unfortunately, the existing implementation of levels was broken
> > because it had a positive value as being below the primary.  The
> > documentation for SetLevel is clear that it should be the other way
> > around.
> > 
> > You'll now need videoLayer->SetLevel(-1).
> 
> And check that (+1 vs. -1) at compile time against what ?

DirectFB version 0.9.25? That's the version number in cvs and 0.9.24 is 
the lastest released version.

> It would be best if no SetLevel() call would be required at all.

Why? Changing the layer stacking is exactly why SetLevel() exists.

Maybe we sould make GetLevel() mandatory (maybe SetLevel() too) so that 
apps would not have to guess how the layers behave. Most drivers would 
just return 1 for the video layer and 0 for the primary layer. We could 
even enforce this by explicitly calling GetLevel()/SetLevel() somewhere 
so that drivers not implementing them would crash ;)

> If there is a different behaviour of some hardware, the DirectFB API
> should make that behaviour uniform.
> 
> Alpha handling on VIA is stange too, as that chipset doesn't seem
> to support ARGB (only AiRGB = (255-A)RGB).

IIRC the AiRGB thing comes from the fact that the hardware blending uses 
this formula:

video * alpha + graphics * (1-alpha)

As the alpha comes from the graphics layer this is the exact opposite 
what one would expect.

The uv_ovl_map_alpha() function appears to always set the opacity to 0 
with ALPHA_WIN_BLEND_GRAPHIC. Has anyone tried setting opacity to 0xF 
with ALPHA_WIN_BLEND_GRAPHIC? Unlikely as that sounds maybe it would 
invert the alpha...


It looks like the driver only allows some basic operation on AiRGB 
surfaces. That restriction seems artificial at least for using AiRGB 
source surfaces because it should be a simple matter of inverting the 
alpha with the blending functions. If the hardware can invert the 
written destination alpha then using AiRGB destination surfaces would be 
possible too.

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/

_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to