wessel@kub.nl (Wessel Kraay) (11/06/90)
Configuration: Vaxstation 3100 running ultrix 3.1
Xserver: Xqvss from the X11R4 mit tape
Some X programs (that use special GC's like xor) do not display correct
on my Xqvss server. When I change display to a Xsun server on a SPARC
(also form the mit tape) but the client is still running on the same,
original host, the programs display fine.
The programs that show this malfunction are:
- Rochester connectionist simulator
- drawbox , a prolog interface to simple Xlib calls like drawing lines, circles
text etc. . (
- Xchess, probably the best known of these three programs. The pieces that are
on a black field are not correctly displayed, (Xchess uses outline bitmaps,
mask bitmaps and GXcopy, GXor, GXandInverted, GXinvert contexts)
Any hints are welcome,
-----------------------------Wessel Kraaij---------------------------
Institute for Language Technology and Artificial Intelligence
ITK
Tilburg-University E-mail: wessel@kub.nl
p.o box 90153
5000 LE Tilburg-Netherlands phone: (+31) 13 663117
---------------------------------------------------------------------mouse@LARRY.MCRCIM.MCGILL.EDU (11/10/90)
> Some X programs (that use special GC's like xor) do not display > correct on my Xqvss server. When I change display to a Xsun server > on a SPARC (also form the mit tape) but the client is still running > on the same, original host, the programs display fine. This could be the common XOR mistake. Is the qvss a color server and the SPARC a monochrome? If so, the problem is probably programmers not thinking about how GXxor works and carelessly drawing with the foreground (or sometimes the background) color and function GXxor, which will work correctly only when the background (resp. foreground) color is 0. On a monochrome display, this is true often enough that the bug goes unnoticed, but it shows up big-time on color machines. > - Xchess, [...]. (Xchess uses outline bitmaps, mask bitmaps and > GXcopy, GXor, GXandInverted, GXinvert contexts) Aha. On a color display you basically never want to use GXinvert (or the related GXandInverted), not unless you have very carefully arranged your colormap so that you're sure it does the right thing. (The only exception is when it's being used to copy bitmaps to other bitmaps preparatory to drawing them on the screen.) As for fixing it, I can't offer anything concrete without seeing the code. Basically, you have to go through and make certain that none of the operations used in the GCs make any assumptions about the pixel values corresponding to the colors used. Anything but GXcopy is dangerous on a color display; anything but GXcopy, and GXxor with carefully-specified colors, is probably useless unless you have set up your colors with XAllocColorPlanes (or have a decomposed-colormap display) and have thought out precisely what each operation does. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
envbvs@epb2.lbl.gov (Brian V. Smith) (11/10/90)
In article <9011091619.AA28709@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU writes: |> > Some X programs (that use special GC's like xor) do not display |> > correct on my Xqvss server. When I change display to a Xsun server |> > on a SPARC (also form the mit tape) but the client is still running |> > on the same, original host, the programs display fine. |> |> This could be the common XOR mistake. Is the qvss a color server and |> the SPARC a monochrome? If so, the problem is probably programmers not |> thinking about how GXxor works and carelessly drawing with the |> foreground (or sometimes the background) color and function GXxor, |> which will work correctly only when the background (resp. foreground) |> color is 0. On a monochrome display, this is true often enough that |> the bug goes unnoticed, but it shows up big-time on color machines. |> Sorry to rain on your solution, but the qvss is a monochrome server. The qdss is color. Both of these are for Vaxstations. I personally have never seen any problems with XOR on our 4 qvss machines. -- Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL; they don't pay me enough for that.
mouse@LARRY.MCRCIM.MCGILL.EDU (11/12/90)
>>> Some X programs (that use special GC's like xor) do not display >>> correct on my Xqvss server. When I change display to a Xsun server >>> on a SPARC (also form the mit tape) but the client is still running >>> on the same, original host, the programs display fine. >> This could be the common XOR mistake. Is the qvss a color server >> and the SPARC a monochrome? If so, [...]. > Sorry to rain on your solution, but the qvss is a monochrome server. Hmmm. Okay then, I have another possibility... Do the qvss and Sun servers use different values for black and white? It's possible the program is doing xor with a foreground value set to (say) black, determined experimentally by the author. When transported to a server that has (say) black being 0 instead of 1, it breaks.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
willis@ecovsb.ncsu.edu (Bill Willis) (11/12/90)
--
We have met the enemy, and they are us --- Pogo
In article <9011112344.AA21683@Larry.McRCIM.McGill.EDU>,
mouse@LARRY.MCRCIM.MCGILL.EDU writes:
|> Path: ncsuvx!gatech!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
|> From: mouse@LARRY.MCRCIM.MCGILL.EDU
|> Newsgroups: comp.windows.x
|> Subject: Re: GXxor problems on Xqvss
|> Message-ID: <9011112344.AA21683@Larry.McRCIM.McGill.EDU>
||> Hmmm. Okay then, I have another possibility...
|>
|> Do the qvss and Sun servers use different values for black and white?
|> It's possible the program is doing xor with a foreground value set to
|> (say) black, determined experimentally by the author. When transported
|> to a server that has (say) black being 0 instead of 1, it breaks....
|>
|> der Mouse
||>
Yep, they sure do use different values... We ran into that problem in an
application we have been working
on....
Bill Willis, Director willis@ecovsa.ncsu.edu
Engineering Computer Operations willis%ecovsa@ncsuvx.ncsu.edu
Box 7901, School of Engineering
North Carolina State University
(919) 737-2458