running gnome and apps on Xvnc at 16 bpp

Const Kaplinsky const "at" ce.cctpu.edu.ru
Fri, 03 Nov 2000 18:27:19 +0000


>>>>> "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
installation?

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

 * gv, kghostview (GhostScript interpreter fails to render documents);

 * lyx-1.0.4pre8 ("In flvisual.c[217]: Can't find an appropriate
   visual").

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