running gnome and apps on Xvnc at 16 bpp

Const Kaplinsky const "at" ce.cctpu.edu.ru
Fri, 03 Nov 2000 14:26:31 +0000


>>>>> "VH" == Vlad Harchev <hvv "at" hippo.ru> writes:

    >> Vlad, is the order of color components also matters for Gnome
    >> apps? I mean would they display images correctly if the pixel
    >> format is BGR565 or they need exactly RGB565?

    VH> Yes, it matters too. They should be the same as XFree server
    VH> uses (use xdpyinfo to find out which ones). Please also change
    VH> defaults for 24bit mode and 15Bit mode too for completness
    VH> (someone might use these modes too) to match XFree's orders.

I've prepared a patch which changes both the default order of color
components and the rules used to set bit widths for these components.
For 16-bit color depth, default format is made RGB565, for 24-bit
colors it's RGB888. General rule is the following: the order is always
RGB (but see below about 8bpp), the highest priority color component
is now green, then blue, then red. This means that when (depth/3) is
not an integral number, green component will occupy more bits than red
one. This rule is most correct since our eyes are most sensitive to
green and least sensitive to red. Besides Gnome problems, this is one
more reason to apply this change to Xvnc.

But I've made one exception for components order: for the 8bpp mode
default format has not been changed and is still BGR233. Just to
prevent extra conversions in 8bpp mode. By the way, I wonder do Gnome
programs even run on 8bpp true-color visual? I have no Gnome, but some
of my programs certainly do not like 8bpp truecolor.

Finally, here is the patch:

=== cut ===
Index: Xvnc/programs/Xserver/cfb/cfbcmap.c
===================================================================
RCS file: /home/const/cvsroot/vnc_unixsrc/Xvnc/programs/Xserver/cfb/cfbcmap.c,v
retrieving revision 1.2
diff -u -r1.2 cfbcmap.c
--- Xvnc/programs/Xserver/cfb/cfbcmap.c	2000/11/02 21:05:09	1.2
+++ Xvnc/programs/Xserver/cfb/cfbcmap.c	2000/11/03 10:19:34
@@ -343,15 +343,15 @@
 
 extern int defaultColorVisualClass;
 
-#define _RZ(d) ((d + 1) / 3)
-#define _RS(d) 0
-#define _RM(d) ((1 << _RZ(d)) - 1)
-#define _GZ(d) ((d - _RZ(d) + 1) / 2)
-#define _GS(d) _RZ(d)
+#define _BZ(d) (d / 3)
+#define _BS(d) 0
+#define _BM(d) ((1 << _BZ(d)) - 1)
+#define _GZ(d) ((d - _BZ(d) + 1) / 2)
+#define _GS(d) _BZ(d)
 #define _GM(d) (((1 << _GZ(d)) - 1) << _GS(d))
-#define _BZ(d) (d - _RZ(d) - _GZ(d))
-#define _BS(d) (_RZ(d) + _GZ(d))
-#define _BM(d) (((1 << _BZ(d)) - 1) << _BS(d))
+#define _RZ(d) (d - _BZ(d) - _GZ(d))
+#define _RS(d) (_BZ(d) + _GZ(d))
+#define _RM(d) (((1 << _RZ(d)) - 1) << _RS(d))
 #define _CE(d) (1 << _GZ(d))
 
 #define MAX_PSEUDO_DEPTH    10	    /* largest DAC size I know */
@@ -524,12 +524,21 @@
 		visual->ColormapEntries = _CE(d);
 		/* fall through */
 	    case StaticColor:
-		visual->redMask =  _RM(d);
-		visual->greenMask =  _GM(d);
-		visual->blueMask =  _BM(d);
-		visual->offsetRed  =  _RS(d);
-		visual->offsetGreen = _GS(d);
-		visual->offsetBlue =  _BS(d);
+		if (d == 8) {
+		    visual->redMask = 0x07;
+		    visual->greenMask = 0x38;
+		    visual->blueMask =  0xC0;
+		    visual->offsetRed  =  0;
+		    visual->offsetGreen = 3;
+		    visual->offsetBlue =  6;
+		} else {
+		    visual->redMask =  _RM(d);
+		    visual->greenMask =  _GM(d);
+		    visual->blueMask =  _BM(d);
+		    visual->offsetRed  =  _RS(d);
+		    visual->offsetGreen = _GS(d);
+		    visual->offsetBlue =  _BS(d);
+		}
 	    }
 	    vid++;
 	    visual++;
=== cut ===

-- 
With Best Wishes,
Constantin
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------