some notes about LCD skins

[enigma2.git] / doc / SKINS

diff --git a/doc/SKINS b/doc/SKINS
index 2db4c6f99cc9f9793285c9846191b3f30ccab283..862ba28c63da7650666425f3696a1c5490e0810d 100644 (file)
--- a/doc/SKINS
+++ b/doc/SKINS
@@ -70,3 +70,64 @@ if you're having less than 16 colors in your png file, pngquant generates a
 16color (4bit) PNG, which is not really what we want. Either add more colors 
 (evil workaround), fix enigma (good idea!) or patch pngquant to
 always create 8bit pngs.
 16color (4bit) PNG, which is not really what we want. Either add more colors 
 (evil workaround), fix enigma (good idea!) or patch pngquant to
 always create 8bit pngs.

+
+transparency:
+=============
+
+First, do not mix up transparency with alpha. I agree, both terms refer to
+the same thing, but in our case, it's more complicated. As long as we don't
+run on accelerated graphic, we need to differentiate between these two.
+
+Alpha, in our context, is the ratio between the video and the OSD. Alpha = 0
+means that OSD is completely visible, and no video, whereas Alpha = 1 (or
+0xFF, if you express it so) means that there is only video.
+
+Transparency, on the other hand, is OSD-only. When you have a background,
+say a color, and you want to blit a picture on it, you can mix the
+background with the picture. (*) This allows pixmap with a non-rectangular
+shape.
+
+Because of speed reasons, we don't support real alpha blending when not
+running with acceleration. Instead, we use alpha testing. This means that a
+special color is "transparent", whereas all other colors are not. This
+colors *HAS TO BE AT INDEX 0*. As you can't count on automatic palette
+merging (it's disabled when the target is 32bit, so you you're not
+restricted to 8bit in total, only 8bit per pixmap), you have to tell your
+gfx program to put the transparent color at index 0. This is what's normally
+done, but in case transparency doesn't work correctly, you might want to
+check this.
+
+
+(*) Note, that, technically, if we start with a alpha=1 background (i.e.
+only video), and alphablend on this, we generalized the problem enough that
+we can handle both cases the same. But currently, we have to differentiate
+between them, as we can't always alphablend.
+
+lcd:
+====
+
+Right now, most lcd-skins ("summary screens") are implemented right in the
+python screens. However, you can override them with regular skinfiles.
+
+There is some confusion about the actual size of the LCD. For now, assume it
+to be 132x64 pixel, but think of the fact that some (most?) hardware can
+only display either 128 (dreambox) or 120 (dbox2, dm8000) pixels
+horizontally.
+
+Right now some pixels will be cropped, currently at the right side. This
+will be (hopefully) fixed soon, so that the used pixels are always in the
+center.
+
+So, bottom line:
+
+Design LCD skins for 132x64, with no important items (text etc.) at the
+outermost 6 pixels on each side. In doubt, leave them white.
+
+LCD colorspace:
+===============
+
+current LCDs are not able to display grayscale graphics. For this, there
+will be a 1bit quantization. However, skins should be designed for 8bit
+grayscale (and still look good in 1bit!), because some next-generation
+display might be able to display some shades of gray - likely not 256, but
+maybe 16 or so.