Problems with transparency effects: a possible bug?

[JoJo73]

I open this thread because I want to discuss some issues about transparency effect; it's likely I've found a bug, but before posting a report I'd like to hear the opinion of other people, since it's my first stint with Rockbox's theme tags.

I own an iRiver H10 20GB and the status of the available themes for this player is not optimal: the oldest of them were written before the implementation of modern features such as viewports or bar tags and work poorly on actual version; since I wished to learn to create themes I embarked into the project of fixing and optimizing existing ones, and because my player shares some themes with the iPod and the iAudio M5 (same resolution, but greyscale display) I take care not to break backward compatibility.

The main problem I stumbled upon is the management of the backdrop and the transparency effect: I have written four sample themes to explain what I've found: you'll find them here https://www.dropbox.com/s/ck61upplvx984i2/transparency_tests.zip for your experimentations.

The three themes share the same visual appearance, but each one tests a different way to load a backdrop image: so far they have been tested on a real H10 with official 3.13 release and two simulators: H10 and M5 (both fairly recent - no more than two weeks old) - Since the code is trivial, it would be interesting to know what happens on other players.

So, here's how they work...

the SBS shows:

* Background color: light blue
* Foreground color: red
* Iconset: Tango Grayscale

the WPS shows:

* The inbuilt status bar
* A smooth gradient backdrop
* A descriptive text summarizing the nature of the test

and four bars created with the "%pv" bar tag, each one with its own image and a partially transparent backdrop representing a gauge. Each bar is drawn in its own viewport.

From top to bottom:

* A black and white bar (1-bit color depth); color #0 (black) is used to draw and color #1 (white) is used to represent transparent zones
* A grey scale bar (4-bit color depth); colors #0, #1 and #2 are used for the drawing and color #3 (white) is used for trasparency
* An RGB bar (8-bit color depth); magic magenta is used for transparent zones and magic cyan to draw the text on the bar
* An RGB bar with alpha channel (8-bit color depth)

Test #1 loads the backdrop with the construct

%V(0,0,-,-,-)%VB
%x(bd.bmp)
%V(0,0,-,-,-)

Test #2 does the same, but the image is first preloaded and then displayed:

%xl(x,bd.bmp)
%V(0,0,-,-,-)%VB
%xd(x)
%V(0,0,-,-,-)

Test #3 uses "%X" tag

Test #4 has no backdrop, text is written in a plain viewport which doesn't overlap others.

To perform the test, simply change the volume to observe how the appearance of the bars change. My findings are:

Test #1
BW bar: transparent zones are drawn in the background color rather than showing the underlying backdrop
Greyscale bar: transparent zones are drawn in white
RGB and ARGB bars: transparent zones are drawn correctly when the volume is increased, but incorrectly when volume is decreased

M5 simulator: the backdrop is crudely dithered
Real H10: the display flickers badly when volume changes
H10 simulator: no flickering

Test #2
BW bar: transparent zones are drawn correctly, either when volume is increased or decreased
Greyscale bar: transparent zones are drawn in white
RGB and ARGB bars: transparent zones are drawn correctly when the volume is increased, but incorrectly when volume is decreased

M5 simulator: the backdrop is crudely dithered
Real H10: the display flickers badly when volume changes
H10 simulator: no flickering

Test #3
BW bar: transparent zones are drawn correctly, either when volume is increased or decreased
Greyscale bar: transparent zones are drawn in white
RGB and ARGB bars: transparent zones are drawn correctly, either when volume is increased or decreased,

M5 simulator: the backdrop is nicely dithered (didn't expected this!)
Real H10: the display flickers badly when volume changes BUT the text disappears when the volume changes! This doesn't happen on the M5 simulator
H10 simulator: text disappearance as above, but no flickering

Test #4
Same as test #1


My conclusions are:


* 4-bit bitmaps don't support transparency (the effect is particularly ugly on the SBS screen) - I think it's more a bug than a feature
* "%X" tag implements the correct way to manage transparency + backdrop (and the dithering on grayscale screens is a nice bonus!)
* The flicker is probably my code's fault (can someone suggest me a way to avoid it?) but the disappearance of the text is likely a bug, since doesn't happen on the M5
* "%VB" implementation doesn't work as intended: poor dithering and transparency not working - a serious bug, IMHO, mitigated by image preloading.
* Most of the problems don't affect a particular architecture, therefore a fix would benefit everybody!

Should I open a bug report on Flyspray, or are some of those effects the fault of my code? I'm waiting for advice...

Thanks!

PS: On a side note, I set a backdrop using the context menu. The image was 8-bit color deep and used magic magenta for transparence; the effect was missing: this might be intentional and not a bug, but I think that it would be more consistent if the magic colors were interpreted as such rather than being drawn unmodified.

[saratoga]

Does it happen in the git builds?  3.13 is basically ancient at this point, and a lot of things were broken in it.

[[Saint]]

Does it happen in the git builds?  3.13 is basically ancient at this point, and a lot of things were broken in it.

so far they have been tested on a real H10 with official 3.13 release and two simulators: H10 and M5 (both fairly recent - no more than two weeks old)

[Saint]

[JdGordon]

I'm currently at work so can't really do much investigating but I'll start with a quick answer.

%VB wasnt tested thoroughly outside of colour displays so it is very likely to be just broken on greyscale screens. Transparency can't actually work on that layer also (same as why you're seeing the magic magenta on a background image).
The way %VB works is that there are 2 layers for the displays, without %VB the backdrop image is on the bottom layer and the wps is on the top layer, transparency works as expected. With %VB the backdrop image is removed, any viewports which use that tag then draw onto the bottom layer (without transparency) and the other viewports then use that layer as its backdrop to make transparency work.

If you have a static background then the best thing is to just use %X

[saratoga]

Does it happen in the git builds?  3.13 is basically ancient at this point, and a lot of things were broken in it.

so far they have been tested on a real H10 with official 3.13 release and two simulators: H10 and M5 (both fairly recent - no more than two weeks old)

[Saint]

Read that as 3.13 on two simulators.  Sorry.

[JoJo73]

Transparency can't actually work on that layer also (same as why you're seeing the magic magenta on a background image).

Yes, the term "transparency" has sense only in the context of the WPS layer; an effect that I was trying to achieve was the displaying of the foreground color using magic magenta on the backdrop layer: not useful on monochrome displays but interesting on color ones.

The way %VB works is that there are 2 layers for the displays, without %VB the backdrop image is on the bottom layer and the wps is on the top layer, transparency works as expected. With %VB the backdrop image is removed, any viewports which use that tag then draw onto the bottom layer (without transparency) and the other viewports then use that layer as its backdrop to make transparency work.

So, if my understanding is correct, %VB gives the user the possibility to "patch" an existing backdrop layer with whatever is defined into a view port.
If I'm right, then the problem resides into the bar tag code, which should superimpose its own backdrop picture on a backdrop layer already modified by any existing %VB tag (respecting transparency rules) and then reuse the new, composite, backdrop layer in subsequent redraws.

%VB wasnt tested thoroughly outside of colour displays so it is very likely to be just broken on greyscale screens.

If the above is correct, then the only missing feature here is the dithering.