X-Git-Url: https://git.cweiske.de/enigma2.git/blobdiff_plain/8ad7dd77272a05b9540ef42b3413599e98c048f0..9fe99dbdc8438c0ba062fc1f82087d6a28f9a5f4:/doc/SKINS

diff --git a/doc/SKINS b/doc/SKINS
index 2db4c6f9..862ba28c 100644
--- 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.
+
+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.