[directfb-dev] Re: Request for new DFBDisplayLayerOptions flag

["Andreas Robinson" <andro134@student.liu.se>]

Denis Oliver Kropp wrote:
> Quoting Andreas Robinson:

> > The video is fully visible where the primary layer's alpha is 255, and
> > invisible (= graphics visible) where the alpha is 0.
>
> Does the hardware provide inverting the inverted alpha? ;)

You can fix it if you buy a patch-circuit, an electron microscope and a
really small soldering iron. :-)

> > I could certainly let the user enable this feature by moving the layer
to
> > position -1 in the layer stack ( = make an underlay), but it doesn't
feel
> > quite right, even if it is documented properly.
> >
> > Any ideas?
>
> DSPF_AiRGB (inv. Alpha plus RGB) would be the right pixel format
> for the primary layer with video being an underlay. But I'm not sure
> if the blitter can accelerate alpha blending with this format.

Hmm, it does not look like it does. You can apply an XOR raster operation to
the 3D engine's blits, but only between the source and destination.
DSPF_AiRGB sounds 100% correct, but could be a pain to implement.

If you don't have any objections, I will follow the path of least resistance
and treat the inverted alpha channel as a hardware bug. It will be
documented, along with a workaround, in the driver's readme.

Regards,
Andreas

PS

Here is how one would enable the underlay and per-pixel alpha blending of
the video layer:

videolayer->SetLevel(videolayer, -1);

Here is the hardware bug workaround:

void InvertSurfaceAlpha(IDirectFBSurface* surface)
{
    int w,h;

    surface->SetColor(surface, 0, 0, 0, 0xff);
    surface->SetDrawingFlags(surface, DSDRAW_XOR);
    surface->GetSize(surface, &w, &h);
    surface->FillRectangle(surface, 0, 0, w, h);
}

FillRectangle is pretty fast (435 Mpixels/sec at 32 bits) so it should be
workable.

DS



-- 
Info:  To unsubscribe send a mail to ecartis@directfb.org with 
"unsubscribe directfb-dev" as subject.