Re: [Linux-fbdev-devel] Alpha blending (fwd)

[Geert U. <ge...@li...>]

---------- Forwarded message ----------
Date: Tue, 3 Apr 2001 18:03:38 +0200 (CEST)
From: Geert Uytterhoeven <ge...@li...>
To: Scott A McConnell <sam...@co...>
Cc: Geert Uytterhoeven <ge...@li...>
Subject: Re: [Linux-fbdev-devel] Alpha blending

	Hi Scott,

> > That's something different. `transp' in fbdev is about transparency of the
> > screen (for a video underlay or so), not about transparency of objects to be
> > blended together on the screen.
> 
> I must be missing something...
> 
> My understanding of 32-bit color is [RGBA|ARGB] (8888) where A is the Alpha
> channel.
> 
> "Which is generally normalized to 0/1." But does not have to be.
> "The alpha value is used to control the blending, on a pixel-by-pixel basis, of
> two images.
> new pixel = (alpha)(pixel A color) + (1-alpha)(pixel B color)"
> [Video Demystified, by Keith Jack]

That's correct.

> Looking at skeletonfb.c:xxx_setcolreg...
> 
>  if (is_cfb32)  /* RGBA 8888 */
>      ...fbcon_cmap.cfb32[regno] = ((red & 0xff00) << 16) |
>       ((green & 0xff00) << 8) |
>       (blue & 0xff00) |
>       ((transp & 0xff00) >> 8);
> 
> It looks to me like transp = Alpha.  I call the above: pixel by pixel alpha

Yes.

> blending.
> 
> With the above I can support a 32-bit framebuffer and support pixel-by-pixel alpha
> blending.
> Either in software or hardware and the frame buffer API does not prevent me from
> doing this..
> (Yes? No?)
> 
> I assume the answer is Yes.

Note that `pixel A' in your example above is a pixel from the screen. But
there's no `pixel B' in te equation.

`pixel B' is something from a different source, e.g. video underlay.

It's not for generic alpha blending of 2 two pixels.

> Based on the discussion it appears that your main concern is text/console support.

In the kernel, that is.

> I am wondering if a slightly larger scope should be applied. I am trying to
> understand where the line
> on acceleration and other "advanced  graphics" features should be drawn in
> reference to the frame buffer.
> 
> In the past James S. told me everyone is on their own for acceleration/display
> list...
> 
> But there are now three functions in the API that deal with rectangular areas.

Yes, they are there becasue they are the graphics primitives to support a text
console.

> There is a real desire to be able to set alpha values on rectangular regions.
> Perhaps not in a console ;-) but certainly by widget sets and graphic systems like
> Microwindows and X.
> 
> Which is what prompted my question about adding an alpha value to the rectangular
> region functions.
> Think about hardware that can support multiple surfaces, perhaps one is video
> (like you mentioned) and the other is we want to generate text on top of it.  This
> happens on sports programs all the time.  On some if you look close you can even
> see the video behind the text.

Yes, that's already possible with the current API.

> I guess what I am asking is: Can we design an API that provides access to the most
> common 2-D acceleration functions provided by hardware?

The question here is: what is a `common 2-D acceleration function'? You'll
always have hardware that can do more than the `common 2-D acceleration
functions'. It's far from trivial to define `common 2-D acceleration functions'
that provide good performance and are flexible (future hardware?). That's why
we decided not to impose any restriction on acceleration and do it all in
userspace.

And the picture gets even more complex when talking about 3D...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds