jonh@pogo.WV.TEK.COM (Jon Howell) (06/07/91)
>On this subject: is anyone else irritated by the fact that many >apps that use colour mess up each other's colours? Finder, ResEdit 2.1 >and MacX spring to mind. I wouldn't mind so much if the background app >was messed up and was OK when it moved to the foreground, but sometimes >things stay mashed (for example, yesterday, the delicate shade of grey >in window borders became a delicate shade of purplish brown in all >applications). This bugs me too. I love playing with MandelZot in 256 glorious colors, so I don't mind so much when it's displaying that the background looks odd. However, when I switch forward to finder, the colors stay mapped this way. Finder thinks it has only got a few to work with, so until I quit MandelZot, I'm stuck with 1-bit icons and dull menubars. There's no good reason for this, since I really don't care if my Mandelbrot window (or PhotoShop window, or whatever) looks funky when I'm not paying attention to it. To add insult to injury, MandelZot HIDES its window when it's not in the foreground, so the system is saving precious palette slots for an application that's not even using them at the moment! Grr. Haven't tried leaving MandelZot with "Hide MandelZot" in the application menu, but the point is this reallocation of palettes should happen automagically. --Jon "trying to get accused of being a whiner and using quoted middle names like people from a.f.u." Howell -- _____ ___ _ _ Jon Howell: jonh@pogo.wv.tek.com | My life's quest is to |_ _| / _ \ | \ | | 6417 Sorrel | find a computer to call for a _| | | |_| | | \ \ | West Linn, OR 97068 | UUCP login (mail & news) that's |___| \___/ |_| \_| 503/657-7964 | local to 503/657- or 206/756-
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (06/07/91)
jonh@pogo.WV.TEK.COM (Jon Howell) writes: >This bugs me too. I love playing with MandelZot in 256 glorious colors, so >I don't mind so much when it's displaying that the background looks odd. >However, when I switch forward to finder, the colors stay mapped this way. >Finder thinks it has only got a few to work with, so until I quit MandelZot, >I'm stuck with 1-bit icons and dull menubars. There's no good reason for >this, since I really don't care if my Mandelbrot window (or PhotoShop window, >or whatever) looks funky when I'm not paying attention to it. I would bet that the Finder is using "courteous" colors, which don't cause the palette to be reorganized even when such a window is in front. -- //----------------------------------------------------------------------------- Mark Lanett mlanett@uiuc.edu Software Tools Group, NCSA
mjkobb@media-lab.media.mit.edu (Michael J Kobb) (06/07/91)
In article <11024@pogo.WV.TEK.COM> jonh@pogo.WV.TEK.COM (Jon Howell) writes: [original attribution lost] >>On this subject: is anyone else irritated by the fact that many >>apps that use colour mess up each other's colours? Finder, ResEdit 2.1 >>and MacX spring to mind. I wouldn't mind so much if the background app >>was messed up and was OK when it moved to the foreground, but sometimes >>things stay mashed (for example, yesterday, the delicate shade of grey >>in window borders became a delicate shade of purplish brown in all >>applications). I have a nifty fkey called RestoreCLUT which, when invoked, reloads the system CLUT and refreshes the screen. This works great when quitting/switching from apps that aren't smart about this. It works fine for me under System 7. I thought it was at sumex, but if not, I'll email the author and see if he'd mind my posting it. --Mike
elliott@veronica.cs.wisc.edu (James Elliott) (06/07/91)
In <1991Jun7.012621.10493@ux1.cso.uiuc.edu> ml27192@uxa.cso.uiuc.edu (Mark Lanett) writes: >I would bet that the Finder is using "courteous" colors, which don't cause the >palette to be reorganized even when such a window is in front. That's possible, but I'm surprised that an application as fundamentally imprtant as the Finder would do this. I have a hard time complaining about the very rare times that colors get messed up on the Mac, though. The Palette Manager is a wonderful thing. Having used 8-bit color on Unix workstations, I'm more used to the colors in background windows becoming total garbage and staying that way, most disconcertingly. Watching background windows on the Mac redraw themselves in the best available colors is truly delightful. -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu
dplatt@ntg.com (Dave Platt) (06/10/91)
In article <11024@pogo.WV.TEK.COM> jonh@pogo.WV.TEK.COM (Jon Howell) writes: >This bugs me too. I love playing with MandelZot in 256 glorious colors, so >I don't mind so much when it's displaying that the background looks odd. >However, when I switch forward to finder, the colors stay mapped this way. >Finder thinks it has only got a few to work with, so until I quit MandelZot, >I'm stuck with 1-bit icons and dull menubars. There's no good reason for >this, since I really don't care if my Mandelbrot window (or PhotoShop window, >or whatever) looks funky when I'm not paying attention to it. > >To add insult to injury, MandelZot HIDES its window when it's not in >the foreground, so the system is saving precious palette slots for an >application that's not even using them at the moment! Grr. Haven't tried >leaving MandelZot with "Hide MandelZot" in the application menu, but the >point is this reallocation of palettes should happen automagically. It's important to distinguish between palettes (which are local to the application and window, and tend to remain static) and the device's color table (which is a dynamic, shared resource of limited size, and whose management is the responsibility of the Palette Manager). The general rule, as I read Apple's documentation, is that applications should request the colors that they want, and that the System is responsible for managing the actual set of colors allocated in the device's color table. MandelZot does this, as best as I could manage. It's true that it does not deallocate its windows' palettes when it switches into the background (either hiding the windows, or not). This is supposed to be unnecessary, since the Palette Manager gives priority to the frontmost applications' requested set of colors. I've noticed the same tendency of the Finder controls (scrollbars, etc.) to revert to Plan B when MandelZot is running. The same thing occurs if another color-hungry application (e.g. Giffer or Image) has run, and has not yet exited. I believe we're seeing an interaction of three factors: [1] A color-hungry application has been run, has a window open, and has requested lots of colors. The Palette Manager has given it most of the device's colortable, including the entries used by Apple's pastel tints. [2] The Finder has been switched forwards... but the Finder does _not_ request lots of colors in its palettes. It seems to be satisfied with just black and white and (perhaps) a shade of gray or two. For this reason, when you switch the Finder forwards, the Palette Manager finds that the existing device colortable satisfies the Finder's needs, and it does _not_ update the colortable or force a screen redraw. [3] The new Window/Control Manager color-management code finds that the pastel tints it wants are not available, and reverts to Plan B (old- style scrollbars). It seems unwilling to try Plan A.5... using any of the existing colors in the color table. There are certainly some things I could do to MandelZot, to force it to disgorge its palette entries when it was switched into the background. I'd probably have to set up a new palette with a minimal set of colors, activate it, and dispose of the old one... and then rebuild the new one when the program was once again brought forwards. I'm nervous about doing this, because [A] it's a kluge, and [B] it will probably force _every_ window on the screen... Finder, MandelZot, or innocent-third-party-application... to be redrawn every time MandelZot is juggled forwards or back. I have seen a few applications which do this sort of thing (QuickGIF is one), and I find the result rather jarring. I will give the matter some thought, however. In the meantime... you could probably work around this problem by creating a MandelZot colorset which contains only about 128 colors. MandelZot will build a palette large enough for these colors, plus a few "overhead" colors (black, white, 50% gray). This should leave plenty of colors for use by other applications. With a bit of luck, the pastels upon which the Window Manager is dependent will not be preempted from the device's colortable, and you'll still have your colored scrollbars to brighten up your day. -- Dave Platt VOICE: (415) 813-8917 Domain: dplatt@ntg.com UUCP: ...apple!ntg!dplatt USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
russotto@eng.umd.edu (Matthew T. Russotto) (06/11/91)
In article <1027@goblin.ntg.com> dplatt@ntg.com (Dave Platt) writes: >I believe we're seeing an interaction of three factors: > >[1] A color-hungry application has been run, has a window open, and has > requested lots of colors. The Palette Manager has given it most of > the device's colortable, including the entries used by Apple's > pastel tints. > >[2] The Finder has been switched forwards... but the Finder does _not_ > request lots of colors in its palettes. It seems to be satisfied > with just black and white and (perhaps) a shade of gray or two. For > this reason, when you switch the Finder forwards, the Palette > Manager finds that the existing device colortable satisfies the > Finder's needs, and it does _not_ update the colortable or force a > screen redraw. > >[3] The new Window/Control Manager color-management code finds that the > pastel tints it wants are not available, and reverts to Plan B (old- > style scrollbars). It seems unwilling to try Plan A.5... using any > of the existing colors in the color table. Suggested kludge: pltt 0 is used for any window which doesn't have its own palette (and presumably, the Finder's windows don't, or there wouldn't be a problem). Give the Finder a pltt 0 resource containing the colors needed for the controls. I used this kludge in the opposite direction to keep the palette manager from interfering with an application which needed full control of the color table-- I made a pltt 0 with only black and white. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.