burzio@mmlai.UUCP (Anthony Burzio) (08/01/89)
I was using the new X Window Systems' ability to output starbase to a window, when I stumbled onto a very interesting thing: When the cursor enters the starbase window, the color maps change just like I supposed they would. Unfortunately, the REST of the screen turns a kind of reddish-orange extremely distracting hue. Like groovy! Unfortunately, this is somewhat distracting. Has anybody else noticed this? Is this a "feature" to draw attention to the new facility? Couldn't a black background replace the outside windows, so the day-glow orange colors couldn't be seen? I need my shades..:-) Computers: HP370 TurboSRX and HP360 CH, running 6.5 HP-UX. Problem (feature?) on both machines. ********************************************************************* Tony Burzio * Gak! Martin Marietta Labs * mmlai!burzio@uunet.uu.net * *********************************************************************
kam@hpcvlx.HP.COM (Keith Marchington) (08/02/89)
Yes Tony, we have noticed it and in reality, it is intentional. Here's the scenario: Starbase has a notion of a default setting of the colormap. I.e. when a program gopen's a "device" with either RESET or INIT specified in the mode field, the program can assume that the colormap is set up in a particular fashion. Many Starbase programs take advantage of this fact and do not bother to set up the colormap beyond that. X, on the other hand, assumes nothing about the initial state of the colormap. It allocates BlackPixel and WhitePixel in the default colormap, but beyond that the rest of the colormap is in an "unknown" state. Clients allocate pixels as need in what amounts to a random order. Now, how do we make these two systems work together. Well, X11 has the notion of virtual colormaps. I.e., a client can allocate a whole colormap and set it up in any fashion it desires. Then when any windows that have specified this colormap get the color focus (which usually follows input focus) the colormap is installed in the hardware. For displays that support only one colormap in hardware, this produces an interesting effect most refer to as "technicolor." So, since Starbase applications that are gopen'd with INIT | RESET assume that they have a particular colormap and full and unlimited use of that colormap to change as they see fit, we decided that when an X window is gopen'd with INIT | RESET, we would create a colormap for that window and initialize it in the Starbase fashion. In this way, old "window dumb" Starbase programs could continue to run and be visually correct without running rough-shod over the hardware colormap. And X applications needn't worry. The side effect, as you have seen is that when the Starbase window is visually correct, other windows are not. Please note though that this phenomenon is not restricted to Starbase applications. Other X applications are beginning to take advantage of virtual colormaps also and I expect to see this more frequently. Of course, in time we should see hardware capable of supporting colormaps on a per-window basis which will reduce the amount of "technicolor" that we must put up with. Ah, the price of flexibility! Keith
stroyan@hpfcdc.HP.COM (Mike Stroyan) (08/02/89)
> I was using the new X Window Systems' ability to output starbase > to a window, when I stumbled onto a very interesting thing: When > the cursor enters the starbase window, the color maps change just > like I supposed they would. Unfortunately, the REST of the screen > turns a kind of reddish-orange extremely distracting hue. Unfortunately, this is a feature. If you are using a Starbase program, (or Xlib program), that changes all of the colors in its colormap, then the windows using other colormaps will not look correct. The X11 server is doing the best that it can to come up with more colors than it has resources to produce. It changes the hardware colormap settings to the values correct for the colormap focus window, and the colors in the other windows are forced to change as well. Since multiple windows may be meant work together with equivalent colormaps, the X11 server would be presumptuous to black out the rest of the windows when one window has its colormap installed. There are some ways to reduce impact of the colormap problem. - Use Starbase without the gopen(,,,INIT) flag and allocate colors using the Xlib calls. This will share the default colormap with other X11 clients. It doesn't work in a device independent way. - Use Starbase without the gopen(,,,INIT) flag and allocate colors using the Starbase rgb calls. This will share the installed colormap with other X11 clients. Later changes to the installed colormap will change the colors that were used by Starbase. - Use the xinitcolormap command in the front of .x11start to set up some of the colors in the default colormap to match the Starbase INIT colors. Then those colors will remain the same when a Starbase program's window has its colormap installed. Mike Stroyan, stroyan@hpfcla.hp.com
burzio@mmlai.UUCP (Anthony Burzio) (08/02/89)
In article <101950043@hpcvlx.HP.COM>, kam@hpcvlx.HP.COM (Keith Marchington) writes: > course, in time we should see hardware capable of supporting colormaps > on a per-window basis which will reduce the amount of "technicolor" > that we must put up with. Thanks to all the HP gurus who have replied to my query. Hmmm... Time to get out my scissors and construction paper and make a mask. Neato! I can finally get a tan while working on my computer! :-) But seriously, multiple color maps are a great thing to throw on the SuperchargerSRX upgrade wish list, along with enough overlay planes to get see-thru plus all 256 colors so you really get 2 useable X screens. Now if I can figure out why sendmail and the lp daemon-startup in /etc/rc completely ignore YP references on my clients. I was reading TFMs and it said to remove all but the cluster host names from /etc/hosts. When I did this, sendmail lost track of all other nodes. When I removed all accounts from /etc/password except root and the YP "go-look-for-other- stuff-in-the-YP-server" entry, the lp daemon complains that the lp administrator isn't in the database(?) If you have a complete hosts table on the client, and put lp back into the clients' passwd file, the problems go away. This, however, defeats YP big time. Everything else works fine. Systems (all have latest HP-UX versions): -------------------------------------------------------Net | | | 835 370 360 (Master server) (client root) (client discless to 370) If this were one of my own programs (or xbiff from the X contrib tape) I'd recompile like the instructions in the manual said. What's to do when it's an HP-UX system source that needs this treatment? I asked the support center, but I guess I ask questions that are too hard, because they take a couple months now-a-days to call back ;-) ********************************************************************* Tony Burzio * Happiness is an 835 that is around just Martin Marietta Labs * to run the kaleidoscope program... mmlai!burzio@uunet.uu.net * *********************************************************************
chan@hpfcmgw.HP.COM (Chan Benson) (08/02/89)
For your TSRX, check out running the server in combined mode (see page 3-4 in the "Starbase Programming with X11" manual). This at least prevents your window borders from "going technicolor". -- Chan Benson HP Fort Collins
kam@hpcvlx.HP.COM (Keith Marchington) (08/04/89)
/ hpcvlx:comp.sys.hp / chan@hpfcmgw.HP.COM (Chan Benson) / 9:48 am Aug 2, 1989 / >For your TSRX, check out running the server in combined mode (see page 3-4 >in the "Starbase Programming with X11" manual). This at least prevents >your window borders from "going technicolor". > -- Chan Benson > HP Fort Collins >---------- That's a good idea Tony. If you run in combined mode, then xwcreate your Starbase windows with a "depth" parameter of either 8 or 24, then they will be created in the image planes while the rest of X will be in the overlays. You only get one screen this way (with as many as three visual types) but your Starbase programs won't cause a technicolor root window. Keith
burzio@mmlai.UUCP (Anthony Burzio) (08/08/89)
In article <101950045@hpcvlx.HP.COM>, kam@hpcvlx.HP.COM (Keith Marchington) writes: > / hpcvlx:comp.sys.hp / chan@hpfcmgw.HP.COM (Chan Benson) / 9:48 am Aug 2, 1989 / > >For your TSRX, check out running the server in combined mode (see page 3-4 > >in the "Starbase Programming with X11" manual). This at least prevents > >your window borders from "going technicolor". > That's a good idea Tony. If you run in combined mode, then xwcreate your > Starbase windows with a "depth" parameter of either 8 or 24, then they > will be created in the image planes while the rest of X will be in the > overlays. You only get one screen this way (with as many as three > visual types) but your Starbase programs won't cause a technicolor root > window. This is a possibility, but the hpwm screen on the overlay looks really terrible, since there aren't enough overlay planes to handle all 256 colors. I could use this when I know I'll need the MOMA window, but in general use this color deficit could be annoying. Can one of you nice folks at HP run over to the SRXen development team and tell them we need to be able to do X with 256 colors in the overlay planes? ********************************************************************* Tony Burzio * Look mom, there's a racoon, a bear, and Martin Marietta Labs * a film crew in the woods! mmlai!burzio@uunet.uu.net * - The Muppet Show *********************************************************************
defaria@hpcladb.HP.COM (Andy DeFaria) (08/12/89)
>I was using the new X Window Systems' ability to output starbase >to a window, when I stumbled onto a very interesting thing: When >the cursor enters the starbase window, the color maps change just >like I supposed they would. Unfortunately, the REST of the screen >turns a kind of reddish-orange extremely distracting hue. Like >groovy! Unfortunately, this is somewhat distracting. Has anybody >else noticed this? Is this a "feature" to draw attention to the >new facility? Couldn't a black background replace the outside >windows, so the day-glow orange colors couldn't be seen? I need >my shades..:-) I heard, at the HP Graphics Symposium (where were you!?! :-) , somebody say that when he opens a Starbase window the first thing he does is call gescape to read the hardware colormap. This syncs up Starbase and X11 as far as colormaps go. I'm not sure how you work with the colors, or allocate new ones, at this point so I haven't tried this yet. This is also hardware dependent. Can anyone expand on this?