running gnome and apps on Xvnc at 16 bpp

Vlad Harchev 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.

 Fine.
  
>     >> 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
> installation?

 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:

void
render_15_fast_dither(ImlibData * id, ImlibImage * im, int w, int h, XImage *
			xim,
                      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;
  int                 jmp;

  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
>    caught");

 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[217]: Can't find an appropriate
>    visual").

 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,
> Constantin
> 

 Best regards,
  -Vlad
---------------------------------------------------------------------
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
---------------------------------------------------------------------