U4 doesn't render transparency correctly in "colourmap" PNGs

[prl]

For example, on the U4 using the easy-skin-aus-hd skin, if you display MENU>AutoTimer or MENU>Power the backgrounds of the large icons on the left of the screen do not blend with the screen background. The dark background parts of the icons are still a bit transparent (you can still see the live TV through them a bit), but they are not as transparent as the screen background (as though the opacity of the screen and the icon has been added). It happens for all the icons in the Power screen: there's a different icon for each menu option.

This doesn't happen with those same icons on the T series.

The underlying issue seems to be that the images are 8-bit colourmap PNGs.

I can work around this for the AutoTimer icon in two ways, either by changing the ePixmap alphablend attribute from on to off or by using Gimp to convert the icon from 8-bit colourmap to RGBA. Both seem to work on both U4 and T4.

On the U4, the pixmap background matches the screen background only if alphatest is off. On the U4, the pixmap background matches the screen background if alphatest is on or off, but not if it's blend.

Why does the U4 render 8-bit colourmap images differently from the T4? Is it because one supports alpha blanding in hardware and one doesn't?

What's the best way to fix this - as a bug in U4 (or T series) rendering, by changing the alphablend setting or by changing the pixmap type?

What is alphablend supposed to do, anyway?

[peteru]

On the U4, the pixmap background matches the screen background only if alphatest is off. On the U4, the pixmap background matches the screen background if alphatest is on or off, but not if it's blend.

I suspect that one of the above was supposed to be T4, the other U4? Which is which?

aplhatest is supposed to be a switch to choose between simple single bit transparency test, like GIF (either transparent or solid) or a full transparency channel with 256 levels (like PNG) for full pixel blending. There are several possible blending modes that depend on source and destination formats, as well as scaling. The U4 seems to support more of those combinations whereas the T-series does not appear to implement many/most. This is for hardware accelerated modes. There's also software based fallback.

It's very likely that the U4 behaviour is "more correct" than T4. If you have a workaround to provide consistent behaviour by manipulating the graphics assets, please go ahead.

[prl]

On the U4, the pixmap background matches the screen background only if alphatest is off. On the U4, the pixmap background matches the screen background if alphatest is on or off, but not if it's blend.

I suspect that one of the above was supposed to be T4, the other U4? Which is which?

aplhatest is supposed to be a switch to choose between simple single bit transparency test, like GIF (either transparent or solid) or a full transparency channel with 256 levels (like PNG) for full pixel blending. There are several possible blending modes that depend on source and destination formats, as well as scaling. The U4 seems to support more of those combinations whereas the T-series does not appear to implement many/most. This is for hardware accelerated modes. There's also software based fallback.

It's very likely that the U4 behaviour is "more correct" than T4. If you have a workaround to provide consistent behaviour by manipulating the graphics assets, please go ahead.

I think the consistent alphatest (at least for the 8-bit pixmap cases I looked at) is off. Converting the AutoTimer pixmap from 8-bit colourmap to RGBA about doubles its size.

There are a few other oddities in images in the skins, one is that Full-Metal-Wizard pulls some images from the easy-skin-aus-hd even though in some cases the files already exist in Full-Metal-Wizard, sometimes the same, and sometimes as a more stylishly compatible image (e.g. for the AutoTimer image).

The other is that many (perhaps most) of the pixmap filenames in the builtin skins are prefixed by the skin name for no apparently good reason. All it does is prevent fallback to the corresponding image in the default skin.

[peteru]

Yes, skins are a mess, down to the pixels. Just because you see a widely used anti-pattern doesn't mean it should be done that way.

I would not worry about image file size too much at this stage. 4kB vs 8kB is not really an issue when you have hundreds of MB up your sleeve in flash and tens of MB available in RAM.

[IanSav]

Hi Prl,

Have you tested OverlayHD on the U4? Are the compressed images I use also causing grief?

Regards,
Ian.

[prl]

IIRC the images in OverlayHD are OK. The issue only seems to affect 8-bit colourmap PNGs, not RGBA ones.

[IanSav]

Hi Prl,

Ta.

Regards,
Ian.

[prl]

IIRC the images in OverlayHD are OK. The issue only seems to affect 8-bit colourmap PNGs, not RGBA ones.

I just checked. The AutoTimer and Power screen images do display correctly in OverlayHD on the U4, but that's not the reason. Both lots of images for those screens (easy-skin-aus-hd and OverlayHD) are 8-bit colourmap PNGs. The critical difference is that the easy-skin-aus-hd images have a partially transparent black background that's intended to match the screen background, while the OverlayHD images have a completely transparent background that simply lets the screen background show through.

The transparent background is no doubt to allow for screen background colour choice in OverlayHD, but it has the side-effect of not causing the blending problems that I'm seeing with those images in easy-skin-aus-hd.

[prl]

I'm most of the way through converting the icons that have problems displaying on teh U4 from 8-bit colourmap to RGBA.

Along the way, I've noticed that the backup selection screen uses the menu/mainmenu_tasks_timer.png icon and not menu/mainmenu_tasks_backup.png. That may be that the menu/mainmenu_tasks_backup.png icon is in easy-skin-aus-hd style rather than the square task icons used (mostly) in Full-Metal-Wizard (e.g. in the main menu, MENU from live TV and in the Power screen, MENU>Power).

Does anyone know where these Full-Metal-Wizard icons come from?

[IanSav]

Hi Prl,

Jai created them and I compressed them for him.

Regards,
Ian.

[prl]

...
Jai created them and I compressed them for him.
...

Thanks, Ian.

Do you happen to have a set of blank icons for them that don't have a pattern?

[prl]

On the U4, the pixmap background matches the screen background only if alphatest is off. On the U4, the pixmap background matches the screen background if alphatest is on or off, but not if it's blend.

...

Here's a summary of how the frame/*.png and menu/mainmenu*.png combine with the background of the screens with the three alphatest values. The screen background has transparency 0x44 (68), where 0 is fully opaque and 255 is fully transparent. On the same scale, the background transparency of the frame PNGs is 0x44, and background field transparency of the menu PNGs is dithered between 0x44 and 0x33 (with most values being 0x44).

Code: Select all

                 T4                  U4

           RGBA   cmap-8       RGBA   cmap-8
off          ok       ok         ok       ok
on           ok       ok         ok      nok
blend       nok      nok        nok      nok

The "ok" and "nok" are just for the setting suitability for this purpose, of embedding an image with a translucent background in a screen background with the same colour and transparency. In the "ok" entries, the transparency of the image background areas matches the transparency of the screen background. In "nok" the transpaency doesn't match, and the effect is to make the resulting background area of the image much less than that of the rest of the screen.

Of particular note is that the combination U4/cmap-8/on appears to do the same as U4/cmap-8/blend.

That means that the only alphatest value that is compatible with all combinations of T/U series, RGBA and cmap-8 images is "off".

[peteru]

Is the T4 using software compositing in enigma2 and is the U4 using hardware acceleration? If so, it should be possible to get consistent results by forcing the U4 builds to use software compositing as well.

Look for FORCE_NO_BLENDING_ACCELERATION and FORCE_BLENDING_ACCELERATION

[prl]

Is the T4 using software compositing in enigma2 and is the U4 using hardware acceleration? ...

No idea. Something's certainly different between them, but I think it's probably the U4 that's not doing the right thing.

[peteru]

If you follow the logic behind the two defines above, you should get your answers. There are comments that suggest that hardware acceleration seems to be almost universally broken, or at least implemented in a way that is not compatible with the way enigma2 code wants things to be.

It should be easy enough to tweak your local build of enigma2 and re-run the tests.

[prl]

I'm doing a U4 build with FORCE_NO_BLENDING_ACCELERATION set now.

[IanSav]

Hi Prl,

Thanks, Ian.

No problem.

Do you happen to have a set of blank icons for them that don't have a pattern?

No, I only received the finished artwork. I don't think I kept any of it anyway.

Regards,
Ian.

[prl]

OK. Thanks. I'll see what Jai has.

[prl]

I'm doing a U4 build with FORCE_NO_BLENDING_ACCELERATION set now.

Setting FORCE_NO_BLENDING_ACCELERATION fixes the problem.

[prl]

Bug #629: alphatest="on" rendering incorrect for 8-bit colourmap pixmaps on U4

Fix submitted.

[peteru]

Before merging the change, I was curious to find out what it would take to make the hardware acceleration work properly. First stop was to look at enigma2 software implementation. That's as far as I got, because I can already see inconsistencies there. I think the code may require an audit (and probably a refactor - the copy-pasta force is strong in that code!) before any specific implementation can be declared correct or incorrect.

To be more specific, looking at the blit() implementation in gpixmap.cpp, I can see that the scaled and non-scaled versions of the code implement a different pixel test for the blitAlphaTest case. We have if (pixel & 0x80000000) in scaled (nearest neighbour) version and if (!((*src)&0xFF000000)) in the non-scaled version. Or in other words, one tests only the high bit, whereas the other tests the entire byte.

The hardware supports a reasonably full featured set of compositing operations, including pre-multiplied alpha. It ought to be possible to get the hardware acceleration to work - possibly better than the enigma2 software implementation. However, to get there, it would be handy to have a standalone set of unit/regression tests, together with some kind of third party reference to serve as an arbitration point when enigma2 implementation and hardware implementations differ. It's a non-trivial amount of work that I don't have time for.

I could merge the hack that forces all boxes to use the enigma2 software implementation. This would give consistent results on all Beyonwiz boxes. It's stop gap measure - I would prefer a proper correct implementation. Especially since this area seems to be currently getting some attention in OpenPLi, OpenATV and OpenViX.

[prl]

I'd be happy to have a go at fixing it. I'd also wondered whether the code in bcm.cpp: bcm_accel_blit() was correct, too, but I have no basis for that other than the fact that it doesn't work as expected for blitAlphaTest.

Before I tackle it, though, I'd want a definition of exactly what blitAlphaTest and blitAlphaBlend are supposed to do, and what is supposed to happen if neither is set. Also, whether having both set is meaningful (in the software implementation, blitAlphaBlend is ignored if blitAlphaTest is set, when accelerated, both flags are given to the opcode that sets the blend mode).

I'm also a bit confused about the logic of this comment:

Hardware alpha blending is broken on the few
boxes that support it, so only use it
when scaling

It seems odd that it would work in the more complicated scaled case, but not unscaled.

The test on !((*src)&0xFF000000) explains the odd result I was seeing for IanSav's new switch picons using blitAlphaTest - some of the "fully transparent" pixels in the alpha plane aren't quite "fully transparent".

[peteru]

A bit more poking around in the code and a whole bunch of tests...

As far as I can see, it is not possible to implement the enigma2 alpha semantics using the Broadcom hardware acceleration capabilities. The Broadcom hardware implements a reasonably flexible set of colour and alpha operators, including custom blend equations. enigma2 seems to have some unusual alpha semantics that are neither flexible nor implementable using the hardware features. To be honest, they actually don't make much sense.

I think the best course of action would be to completely redesign the enigma2 alpha channel handling. Just use an industry standard alpha blending method. Eliminate the alphatest=on mode completely and make it behave the same as alphatest=blend mode. Use a src-alphablend-over-dest mode for colour values and leave destination alpha values alone.

A straight copy blit can be used to set the destination alpha channel to desired base value. Compositing bitmaps with their inherent alpha value should not modify the destination alpha, only the colour components.

I'm not sure who was thinking what when they implemented the current code. There are probably some edge cases where the current implementation may make sense. I'd be interested in knowing about them so they can be worked in to a "normal" compositing implementation.

[prl]

... enigma2 seems to have some unusual alpha semantics that are neither flexible nor implementable using the hardware features. To be honest, they actually don't make much sense.
...

It looks as though they are using the blend equations for colours with associated (pre-multiplied) alpha, not the ones for non-associated alpha. As far as I can tell, the display uses non-associated alpha.

The alpha (A) calculation is the same (here for alpha=0.0 for fully transparent and 1.0 for opaque):
Aout = Asrc + Adst * (1 - Asrc)

But the incorrect calculation (for associated alpha) is used for each colour C:
Cout = Csrc + Cdst * (1 - Asrc)

where it should be:
Cout = (Csrc * Asrc + Cdst * Adst * (1 - Asrc)) / Aout (Aout !=0)
Cout = 0 (Aout == 0)

Doing it this way means more operations (a total of 10 multiplies, 8 adds and 3 divides vs 4 multiplies and 8 adds), and an if statement for each alphablend operation.

That's for the "over" operation in Porter & Duff - Compositing Digital Images.
Or Wikipedia [urlhttps://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending]Alpha compositing: Alpha blending[/url] for the condensed version.

[prl]

... the Broadcom hardware acceleration capabilities. The Broadcom hardware implements a reasonably flexible set of colour and alpha operators, including custom blend equations. ...

lib/gdi/bcm.cpp: bcm_accel_blit() doesn't seem to support anything like that: it just passes the 1-bit blitAlphaTest & blitAlphaBlend flags into the displaylist.

Is there any publicly available documentation of what the BCM graphics accelerator does?

[peteru]

From gpixmap.h:

Code: Select all

void alpha_blend(const gRGB other)
{
#define BLEND(x, y, a) (y + (((x-y) * a)>>8))
	b = BLEND(other.b, b, other.a);
	g = BLEND(other.g, g, other.a);
	r = BLEND(other.r, r, other.a);
	a = BLEND(0xFF, a, other.a);
#undef BLEND
}

I wonder if that implementation is modelled on the BLENDFUNCTION MSDN article, but completely fails to account for the various alpha source scenarios documented there.

Then there is the problem that this is only one of many compositing strategies used in gpixmap.cpp. There are at least a dozen blit cases and not all of them use the same alpha strategy.

As far as publicly accessible information on Broadcom hardware compositing, I can only locate references to various patents. The actual APIs to the hardware are not public. The relevant information can be summarised thusly:

Code: Select all

Colour operations (BlitColorOp):
CopySource,       /* Copy the source color with no blending. */
UseConstantAlpha, /* Blend the source and dest colors using the alpha from the constantColor param */
UseSourceAlpha,   /* Blend the source and dest colors using the alpha from the source pixels */
UseDestAlpha,     /* Blend the source and dest colors using the alpha from the dest pixels */

Alpha operations (BlitAlphaOp):
CopySource,       /* Oa = Sa. Copy the source alpha to the output alpha. */
CopyDest,         /* Oa = Da. Copy the dest alpha to the output alpha */
CopyConstant,     /* Oa = Ca (where Ca is constantColor>>24). Copy the constantColor parameter for the output alpha */
Combine,          /* Oa = Sa*Sa + Da*(1-Sa). Combine source and dest alpha. */

When you perform a blit, you get to choose the colour op and the alpha op independently. There are some constraints. For example, you can't have BlitColorOp=UseConstantAlpha and BlitAlphaOp=CopyConstant at the same time.

There are more advanced APIs that allow for a more complex custom blend equation, but that is a rabbit hole best not entered.

My guess would be that BlitColorOp=UseSourceAlpha and BlitAlphaOp=Combine is the most appropriate choice for a generic solution, but backwards compatibility may suffer. Tests would be required.

I also think that all bitmaps should only be composited to 32-bit destination buffers. This means that only the x->32 cases need to be implemented and all alpha handling can be made consistent by expanding all sources to the full 32bit RGBA values.

The existing code may have been useful a few decades ago, but these days we can expect/mandate 32bit RGBA end to end.

[peteru]

I think I made some sense out of this whole mess.

alphaTest is supposed to test for a "magic" value of srcA=0x00 and when found it leaves the destination pixel intact. In every other case, it is supposed to simply replace dstARGB with srcARGB. This is not possible to easily implement using hardware acceleration because the hardware does not have a facility to perform comparisons on pixel values as part of the blit process.

alphaBlend is supposed to perform a normal pre-multiplied alpha composition.

alphaTest is not suitable for any form of compositing. It is intended to punch holes in the OSD all the way to the video layer. I think most uses of alphaTest are actually misuses where alphaBlend should have been used instead.

The implementation has been inconsistent/buggy for more than 10 years. I'll get some fixes for the enigma2 code out in the next day or so. I'll also update the U4 drivers to provide compatible blit implementations for the alphaBlend and straight copy cases.

The enigma2 software implementation performs blit scaling using nearest-neighbour algorithm. This looks ugly, but is relatively fast. The hardware defaults to anisotropic filtered scaling. I think I'll leave it enabled so that the hardware accelerated scaled images look better.

tl;dr - Don't use alphatest="on" in skins. It's almost certainly not what you want. Use alphatest="blend" and appropriate alpha to achieve proper compositing.

[IanSav]

Hi PeterU,

I have edited OverlayHD to convert all alphatest values to "blend" but until you merge my pending pull requests I can't offer an update to users.

Regards,
Ian.

[IanSav]

Hi PeterU,

On thinking about this wouldn't it make sense to make the Enigma2 / skin default of alphatest="blend" the built in default. This would mean that this string could be removed from all the skins and save lots of space and processing time. We could then add an alphatest attribute if the need arise.

Actually when would anyone want to use alphatest at all?

Regards,
Ian.

[peteru]

It's not that simple. A simple replacement of alphatest="on" with alphatest="blend" isn't going to work for anything that does not have the appropriate alpha channel to go with it.

alphaTest mode still has it's places, as long as you understand how to use the mask, how to stack layers correctly and don't mind the rough edges.

[prl]

It's not that simple. A simple replacement of alphatest="on" with alphatest="blend" isn't going to work for anything that does not have the appropriate alpha channel to go with it.
...

In particular, alphatest="blend" isn't going to work for the easy-skin-aus-hd icons in screens like Power / Restart or for frame pixmaps in either of the pre-installed skins.

It would be OK in OverlayHD, because it uses transparent backgrounds for those screen icons, and doesn't use pixmap frames.*

IanSav's new switch icons don't work in alphatest="on", because their transparent backgrounds don't pass the srcA=0x00 test everywhere where they should.

It would be a fair bit of work removing alphatest="on" everywhere, since it's used more frequently than any other setting in all three skins. The numbers:

Code: Select all

	easy-skin-aus-hd  Full-Metal-Wizard  OverlayHD
	easy-skin-aus-hd  Full-Metal-Wizard  OverlayHD
off		     102		101	    25
on		     243		241	   482
blend		     140		138	   177

[the "off" also counts implicit "off"s where the alphatest attribute is missing]

* I had a go at this as a possible fix for the problem with these icons being displayed incorrectly on the U4. It's relatively easy to lift the coloured areas of the icons and put them on a transparent background (as has been done by Ian in OverlayHD), but that removes the drop shadows on the icons. It's hard to manipulate the transparency mask of these icons, because it is dithered in most of them (probably as a result of them being put into 8-bit colourmapped format), and in the one I was experimenting with, the drop shadow transparancy mask shares some values with the transparency mask of the "reflection" in the bottom of the icon. I tried creating a drop shadow on the extracted coloured parts, but Gimp does the drop shadow differently from the originals, and makes the "reflections" darker than they were. I haven't tried to find out exactly how Gimp does drop shadows to see if there's another way of doing it so it has a similar result as the original drop shadows.

[IanSav]

Hi,

I have decided to back out the changes of all alphatest attributes to blend until this issue is resolved and a final recommendation is made.

Regards,
Ian.

[prl]

... On thinking about this wouldn't it make sense to make the Enigma2 / skin default of alphatest="blend" the built in default. This would mean that this string could be removed from all the skins and save lots of space and processing time. ...

Which processing is reduced? It makes applying the skin faster, but it makes drawing the pixmap slower.

When done in firmware, for unscaled 24-bit ARGB pixmaps and a 24-bit ARGB display, "off" is

Code: Select all

memcpy(dstptr, srcptr, area.width()*surface->bypp)

[per row]

"on" is:

Code: Select all

	if (!((*src)&0xFF000000))
	{
		++src;
		++dst;
	} else
		*dst++=*src++;

[per pixel]

and "blend" is:

Code: Select all

	dst->alpha_blend(*src++);
		++dst;

where alpha_blend() is:

Code: Select all

	inline void alpha_blend(const gRGB other)
	{
#define BLEND(x, y, a) (y + (((x-y) * a)>>8))
		b = BLEND(other.b, b, other.a);
		g = BLEND(other.g, g, other.a);
		r = BLEND(other.r, r, other.a);
		a = BLEND(0xFF, a, other.a);
#undef BLEND
	}

[per pixel]

Actually when would anyone want to use alphatest at all?
...

For simple icons where all pixels are either completely transparent or completely opaque, it's faster in firmware than "blend" and produces similar results, apart from being a bit jaggy. Where the source and destination are both 8-bit colourmapped, "blend" has no real meaning (and is implemented the same way as "on" in the code). It may also be useful where the hardware only has a single-bit alpha plane (there were some 16-bit ARRRRRGGGGGBBBBB displays), but I don't know whether that was a design intention.

[IanSav]

Hi Prl,

I was only thinking about skin size and processing time.

Anyway, I will await the results of your and PeterU's efforts and will update OverlayHD when a clear direction is available.

Regards,
Ian.

[prl]

...
I was only thinking about skin size and processing time.
...

Not much in size - alphatest attributes take up a bit less than 8kB out of about 356kB in the easy-skin-aus-hd and I wouldn't expect it to be much different in the other skins. If space really is an issue, you could save at about 10kB by eliminating non-significant whitespace when doing the build. Removing comments at the same time would also save a bit of space.

The cost of processing an extra attribute at skin read time isn't all that high, and happens only at GUI startup time.

The presence of an alphatest in applying the skin to a GUIComponent attribute doesn't cost a lot, either.

They're all things worth considering, but surely the time to paint the pixmap is also worth thinking about?

[IanSav]

Hi Prl,

We all tend to focus on the areas that interest us the most.

Regards,
Ian.

[prl]

I was responding to your question:

...
Actually when would anyone want to use alphatest at all?
...

and discussion that followed it.

[prl]

Peteru, I see that you've made changes that allow the switch pixmap rendering alphatest to be set to either "off" or "blend" (but not "on") in the config.py code.

Do you have any interest in having it settable (to all three settings) from the <switchpixmap/> skin elements?

I.e. something like:

Code: Select all

	<switchpixmap>
		<pixmap name="menu_on" filename="easy-skin-aus-hd/menu/menu_on.png" alphatest="blend" />
		...
	</switchpixmap>

It's written and partly tested already.

[peteru]

Sure, submit a pull request so that I can see how it's done. The solution in eListboxPythonConfigContent mimics the implementation used in eListboxPythonMultiContent to provide some API consistency. The API is not all that great. If you have a better, generic solution that can be used in multiple places, let's consider it.

[prl]

Sure, submit a pull request so that I can see how it's done. The solution in eListboxPythonConfigContent mimics the implementation used in eListboxPythonMultiContent to provide some API consistency. ...

My change was to make ConfigBoolean.getMulti() return the triple ("pixmap", pixmap, flags) instead of ("pixmap", pixmap), and make the flags optional for backward compatibility. The flags would be set from the alphatest attributes in <switchpixmap/> in the skin.

I'm not sure how using "pixmap_blend" parallels eListboxPythonMultiContent. It allows the blend/mask flags to be set on pixmaps either by the entry type or by setting flags, so the following have the same effect:
(TYPE_PIXMAP_ALPHABLEND, pos[0], pos[1], size[0], size[1], pixmap, backcolor,backcolor_sel, 0)
(TYPE_PIXMAP, pos[0], pos[1], size[0], size[1], pixmap, backcolor,backcolor_sel, BT_ALPHABLEND)

[prl]

I found some information about the BCM7405 (T3 SOC) on a Dreambox blog: https://jb8a8f8.com/support/index.php?t ... mation.53/.

In particular there's an architecture document that covers the graphics engine (starting page 1-43), but doesn't, unfortunately, give its instruction set or much in the way of real details.

I suspect the document that's really needed is 7405-3HDM0x Data Transport, Audio, Video, and Graphics.

[Henk]

I suspect the document that's really needed is 7405-3HDM0x Data Transport, Audio, Video, and Graphics.

https://www.samkear.com/wp-content/uplo ... 02-RDS.pdf

[prl]

I suspect the document that's really needed is 7405-3HDM0x Data Transport, Audio, Video, and Graphics.

https://www.samkear.com/wp-content/uplo ... 02-RDS.pdf

Thanks, but what you've linked to is 7405-1HDM02-RDS General Information, which is the same document as what I posted a link to. I'm looking for 7405-3HDM0x Data Transport, Audio, Video, and Graphics, which I hope has a detailed description of the graphics engine.

[peteru]

I understand that having more documentation is better, but even if you get your hands on it, it's not going to be much use.

The hardware is only accessible through the SDK which abstracts the hardware through many layers. The API available to the drivers (which are closed source) has already been more or less outlined above.

[prl]

I understand that having more documentation is better, but even if you get your hands on it, it's not going to be much use.

The hardware is only accessible through the SDK which abstracts the hardware through many layers. The API available to the drivers (which are closed source) has already been more or less outlined above.

I'm trying to get a handle on what's in lib/gdi/bcm.cpp: bcm_accel_blit() and bcm_accel_fill(), and what might be put in them. In particular, whether the colour key function mentioned in the General Information document can be used to accelerate alphatest="on"

[prl]

Sure, submit a pull request so that I can see how it's done. ...

Pull request submitted.

[peteru]

I'm trying to get a handle on what's in lib/gdi/bcm.cpp: bcm_accel_blit() and bcm_accel_fill(), and what might be put in them. In particular, whether the colour key function mentioned in the General Information document can be used to accelerate alphatest="on"

I looked into it already. The keyer will allow you to replace the alpha value (in either src or dst) based on a comparison against a range of colours. The replacement is a constant alpha value and it is applied before the src and dst pixels are alpha blended. The keyer API does not have a facility to test for an alpha value in src and switch between src or dst, which is what alphatest="on" does.

I used bold to draw attention to the specific limitations that get in the way. Basically the keyer hardware processes the three colour channels and alpha channel in parallel and the combined test for values from the three colour channels switches the alpha channel between copying the existing value or replacing it with a constant.

[MrQuade]

I don't know if it is only because I just noticed it, or if this is new and a result of some of the recent transparency merges, but the infobar icons for play, pause, ff and rew etc.. all look pretty scruffy round the edges where the semi-transparent edge pixels should be. This is on both T and U series.

Apologies for the thread distraction if it was always like that though.....I honestly can't remember these days!!

[prl]

I don't know if it is only because I just noticed it, or if this is new and a result of some of the recent transparency merges, but the infobar icons for play, pause, ff and rew etc.. all look pretty scruffy round the edges where the semi-transparent edge pixels should be. This is on both T and U series.
...

The switch-point for some renderings of alphatest="on" has changed from alpha < 0x80 to alpha == 0 (for alpha=0 for transparent and 0xff for opaque - that's the opposite of how it's defined in skin colours). But some renderings are unchanged.