running gnome and apps on Xvnc at 16 bpp
hvv "at" hippo.ru
Fri, 03 Nov 2000 20:55:34 +0000
On 4 Nov 2000, Const Kaplinsky wrote:
> >>>>> "VH" == Vlad Harchev <hvv "at" hippo.ru> writes:
> >> 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.
> VH> So will the widths and masks match the ones in XFree?
> Yes, now they match pixel formats used in my XFree-3.3.6 installation
> both for 16-bit and 24-bit color depths.
> >> 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.
> VH> You can run any program that is linked with imlib-1.x (the
> VH> problem is with it, not with anything else) to see the
> VH> problem. If you have enlightenment or gqview (not sure), you
> VH> will be able to see that.
> I have not found any programs that use imlib on my machine, but I have
> imlib installed and here is what I've discovered in its config file
> (/usr/etc/imrc in my installation):
> === cut ===
> # This speeds up rendering considerably, but may not work on your hardware
> # due to it bypassing a few layers and byte-twiddling the rendered image data
> # manually, and due to endianess, bit-ordering or RGB ordering it may screw up
> # and not work, so try it.. if things work great!, if not, wait until a
> # renderer for your situation is written, or write one yourself and donate
> # it. It's easy to do, just look at rend.c
> FastRender off
> === cut ===
> I think it's very likely that this setting is the actual reason for
> Gnome problems you have described. Could you please check it in your
No, it doesn't matter. All component's widths and masks are hardcoded into
Imlib's code and logic - see Imlib/rend.c
For example, the piece of code:
render_15_fast_dither(ImlibData * id, ImlibImage * im, int w, int h, XImage *
XImage * sxim, int *er1, int *er2, int *xarray,
unsigned char **yarray)
int x, y, val, r, g, b, *ter, ex, er, eg, eb;
unsigned char *ptr2;
unsigned short *img;
jmp = (xim->bytes_per_line >> 1) - w;
img = (unsigned short *)xim->data;
for (y = 0; y < h; y++)
ter = er1;
er1 = er2;
er2 = ter;
for (ex = 0; ex < (w + 2) * 3; ex++)
er2[ex] = 0;
ex = 3;
for (x = 0; x < w; x++)
ptr2 = yarray[y] + xarray[x];
r = (int)*ptr2++;
g = (int)*ptr2++;
b = (int)*ptr2;
er = r + er1[ex++];
eg = g + er1[ex++];
eb = b + er1[ex++];
if (er > 255)
er = 255;
if (eg > 255)
eg = 255;
if (eb > 255)
eb = 255;
val = ((er & 0xf8) << 7) | ((eg & 0xf8) << 2) | ((eb & 0xf8) >> 3);
er = er & 0x07;
eg = eg & 0x07;
eb = eb & 0x07;
DITHER_ERROR(er1, er2, ex, er, eg, eb);
*img++ = val;
img += jmp;
Note how 'val' is computed. The order of components and their width is
hardcoded into logic and code. All code in rend.c is like this.
I dunno how correct Imlib-2.x is.
> VH> I don't remember any problems running gnome apps on 8bpp
> VH> Truecolor visual. As for programs not liking 8bpp truecolor -
> VH> I guess they are Xaw apps or games.
> I have many programs that do not work correctly in 8bpp mode (that is,
> when I start VNC with "vncviewer -depth 8" command). Several examples:
> * gimp-1.0.2 ("** WARNING **: unable to find a suitable visual for
> color image display", then "/usr/bin/gimp fatal error: sigsegv
I didn't expect this...
> * gv, kghostview (GhostScript interpreter fails to render documents);
Hmm, I didn't expect this from gv.
> * lyx-1.0.4pre8 ("In flvisual.c: Can't find an appropriate
It seems this is the problem of xforms library used by lyx.
> Maybe this software is mostly outdated, but it's sad anyway. And I
> prefer to blame not these programs themselves but rather X system
> complexity - I certainly don't like it.
> With Best Wishes,
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