PNG Transparency

[martin.deimos]

Hey folks,
we at Skin Consortium didn't gave up completely to port our ClassicPro Skinning framework to VLC.
Today i heard of the RC1 release and thought let's check if VLC finally supports well-blended RGBA PNGs.

First of all: transparent PNGs show up at all now, but the blending doesn't work 100% , so lemme show you what i mean:

This is an excerpt of a semi-tranparent PNG - see the tranparent area in the inside of the repeat buton?


This is what VLC renders:

the semitranparent area > 50% is blended w/ #000000 instead of the yellow background everything below 50% is set to 100% yellow

this is how it should blend on a yellow background (how it does in Winamp & Photoshop)


Well i know that the example looks a bit bad, but some ClassicPro skins really take advance of per pixel alpha blending. So is there any trick to get this working for 1.0.0 or is this still a TBD thing?

[Jean-Baptiste Kempf]

Hey, can you supply some test skins for testing, please?

[Jean-Baptiste Kempf]

Btw, 1.0.0-rc1 should be way more stable wrt skins than 0.9

[martin.deimos]

http://stashbox.org/514579/ClassicPro_WIP_001.vlt

this is the edited skin project from one of our Skin Consortium admins.

(Btw, OS = win7)

[martin.deimos]

any ideas?

[3breadt]

Semi-transparency in PNGs was never supported by VLC, and the developers always refrained from tackling that task (To much work, to little devs). I doubt that it will be available in 1.0.

[Jean-Baptiste Kempf]

Hey Daniel,

Do you know if the issue is VLC or our use of libpng?

[3breadt]

Probably it might have something to do with the part where the custom alpha channel is applied to the PNG, a custom mask is created using the alphacolor information and the alpha channel of the PNG. I think this mask is only 1-bit (fully transparent/fully opaque) and thus overrides the actual alpha channel of the PNG.

I took a brief look at the source, but as I don't speak C/C++ I don't fully understand it. But for a start I'll check file_bitmap.cpp, as the transparency mask is computed there, and the way it is done looks suspicious to me. On the other hand the whole graphics handling system (os_graphics.hpp and its implementations) seem to build upon a 1-bit transparency so there might me more work to do to support 256-bit transparency.

[erwan10]

Hi,

Actually, with respect to this transparency issue, two functions are at stake :

/// Draw another graphics on this one
virtual void drawGraphics( const OSGraphics &rGraphics, int xSrc = 0,
int ySrc = 0, int xDest = 0, int yDest = 0,
int width = -1, int height = -1 ) = 0;

/// Render a bitmap on this graphics
virtual void drawBitmap( const GenericBitmap &rBitmap, int xSrc = 0,
int ySrc = 0, int xDest = 0, int yDest = 0,
int width = -1, int height = -1,
bool blend = false) = 0;

The first function doesn't care at all about transparency. The second one fully implements transparency (see the blend parameter to enable or disable it)

The problem is that some controls use the first function (button controls, ...). Others use the second function (skinned playlist, ...).

For the former ones, the result is a bit weird, because all bitmaps .png are loaded at initialization and alpha channel is taken into account right away for their side (see file_bitmap.cpp). Later on, depending on the function used, the other side is computed or not. In the case of a button, the other side is never computed, leading to transparency against #000000.
The case of alpha = 0 (full transparency) is still different and happens to work as a side effect. (Everything is transparent originally)

To wrap it up, much work is already done. Design just needs to be changed a bit to allow for transparency everywhere. One thing though is that it is highly dependent on platforms. Work has to be done twice (X11 and Windows).

Two things for sure :
- libpng is not the issue. this is a pure skins2 issue.
- alpha is coded on 8 bits everywhere (no problem here)


Erwan10

[erwan10]

After some more testing, the issue may come easier than expected. I'm sending a small patch on the mailing list that seems to work out the problem described in this thread.

Erwan10

[Jean-Baptiste Kempf]

Great! I hope you get commit access soon!

[martin.deimos]

heyhey,
seems like there had been some progress during the weekend

also nice to hear that the issue might be fixed! I'm eager to test the stuff as soon a compiled binary exists

[Jean-Baptiste Kempf]

Tomorrow, a new build should come...

[martin.deimos]

thx,
bug seems to be fixed. we might continue prting the ClassicPro Skinning Framework to VLC now

[3breadt]

Yay! At least it is fixed for images blended over another image. But if the background image is semi-transparent the same issue is still there.

[erwan10]

Actually, this patch only worked out the semi-transparency issue for button and checkbox controls (in fact all controls using an AnimBitmap). The other controls still work as before. Especially, an image overlapping another image still doesn't implement semi-transparency. If you think it is important, it should not be too much work ....

Erwan10

[martin.deimos]

IMO stuff should be intuitive for skinners.
i hate stuff like: wtf does the skinning engine now?

So whatever can be fixed should be fixed

[3breadt]

An image overlapping another image still doesn't implement semi-transparency.

IMHO, that is one of the most important uses of semi-transparency in skins2 I can think of. Think e.g. about rounded edges of windows. So please, if you have the time, attempt fixing that, too. Thanks

[erwan10]

Okay, I can give it a try.

Maybe you already have such a skins that I could use for testing ...

Erwan10

[martin.deimos]

just found that the seeker (slider object) doesn't seem to support transparency.
would be cool to get it

[erwan10]

After more testing, I now understand why semi-transparency was not implemented by default. It's not about devs being too lazy to tackle the problem (the code already exists). It's a matter of performance and design.

Implementing it on button/checkbox controls is not painful performance-wise, because those are most often small bitmaps that never need rescaling.

For images, it's another matter. They are everywhere in vlc skins2. They can be large bitmaps, and may need on-the-fly rescaling. In today's vlc(skins2), computing semi-transparency systematically is a few lines of code, but a real big loss in performance. I've tested it!

But, why not merging bitmaps once for all with gimp or another photoshop ? Are there really situations where semi-transparency must be computed in real-time ?

@AltGlass
- for rounded edges, doesn't full transparency (alpha=0) already allow this ?
- also, at the theme level (Windows only), there are the "alpha" and "movealpha" parameters that allow semi-transparent windows

@martin.deimos
- Well, for sliders, why not ..... they are usually small.


Erwan10

[3breadt]

for rounded edges, doesn't full transparency (alpha=0) already allow this ? also, at the theme level (Windows only), there are the "alpha" and "movealpha" parameters that allow semi-transparent windows

Rounded edges would need anti-aliasing -> not possible w/ 1-bit transparency. Alpha/movealpha make the whole window transparent, sometimes one would want to have the controls fully opaque but only the background semi-transparent.

But, why not merging bitmaps once for all with gimp or another photoshop ? Are there really situations where semi-transparency must be computed in real-time ?

Example: an image control which is a background for a set of buttons, which is centered in a resizable window. That image has let's say rounded edges, or a gradient to transparency. That image's transparency would need to be computed in real-time, when resizing.
I somehow can't imagine that there is such a great performance loss when computing semi-transparency. And wouldn't that performance loss only be active when the layout changes, e.g. buttons hovered, window resized etc.?

@martin.deimos: But SliderBackground seem to work.

[erwan10]

Actually, I do agree real-time semi-transparency can be very useful ...

But, enabling it will require more than the few lines of code I first figured out. Additional optimizations are necessary. For example, opaque controls and controls with a 1-bit transparency should be detected at initialization and not be part of the real-time semi-transparency processing. This will take more time to implement and will require some design work before coding anything.

As for the performance problems, it was only obvious for skins with many bitmaps. By performance problems, I mean refreshing a skins when resizing or moving another window on top of it very rapidly. What was done in 1 sec without semi-transparency was done in 3 or 4 sec with semi-transparency. (the PC is a 7-year old vet !)

Erwan10

[martin.deimos]

well, I come from Winamp skin development (tbh, i've also coded the winamp 5.5 default interface bento). Winamp handles transparency PNGs in two ways:

- transparency to canvas: this is what i would expect from VLC as well. everything is blended to a background. resizing will need recalculation of bitmaps (Winamp does not feature a 'live' resize out of the box - it just shows a rectangle - so there isn't a performance impact. Nevertheless you can code live resize in skins. This may impact performance a bit if you use lots of layers/groups/buttons.

- transparency to desktop: this is also known as composite rendering / desktop alphablending. the cool thing about this is that you can smooth edges. But winamp doesn't support DTA on all areas. for example a video or playlist window cannot have DTA. I wouldn't expect VLC to include this. To reduce performance iompact on older machines you can turn DTA off, and the background is blended w/ black if higher than 50% transparent. As a sidenot: Windows Vista / Windows 7 seems to handle windows with DTA much better than older versions (performance is the same or even less )

So why don't u include a checkbox somewhere to enable RGBA on layer. If i remember well, there is already a similar option in extended Prefs.