Fine's Home
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://hea-www.harvard.edu/~fine/Tech/X11visuals.html
Дата изменения: Unknown Дата индексирования: Sun Apr 10 06:58:24 2016 Кодировка: Поисковые слова: р п р п р п р п р п р п |
8-bit PseudoColor will mean that the application is limited to 256 colors. Moreover, these colors are generally shared across all applications. So if some other application is using 245 shades of brown, your application gets black and white (pretty much always allocated, plus those browns, plus up to 9 other colors of your choosing. Unless there's more than that one other application running, in which case the colormap is probably full, and you can't choose any colors.
Of course, 8-bit applications can run with a "private colormap". That means that the application can use any 256 colors of it's own choosing, without competing with other applications. The downside to this is that on most hardware, this results in "colormap flashing". As you move from one application to the next, the entire screen switches to a different colormap, which causes all of the non-current applications to look like psychadelic puke. Some users are willing to live with private colormaps to get adequate colors. Most users however, can not stand it.
If you want your customers to be able to use your program on hardware that is not your hardware, then you have to do this. These two visuals cover the vast majority of what's available from the past decade. In the past, when Pseudocolor reigned supreme, developers only supported pseudocolor. These applications won't work on TrueColor hardware. And now, many developers write applications that only support TrueColor, and won't work for users on older hardware.
Many (most?) systems today support multiple visuals on the same window system. Run the command "xdpyinfo" to see how many visuals you have. Unfortunately, many applications only look at the default visual. Older application developers didn't even write for TrueColor. But newer applications, which support both PseudoColor and TrueColor, often fail to find the TrueColor visual, handing the user a color-intensive application using PseudoColor, when lots of colors are available.
But, if a system has TrueColor, why would it's default visual be PseudoColor? Well, the user of that system may have to run a relic application that does not support TrueColor at all, and does not know how to look past the default visual. Setting the X11 default to be PseudoColor is the only way to allow this application to run. They may need to run some application which support both visuals, but again doesn't look past the default visual. If they need lots of windows from this application, but not lots of colors, they may prefer Pseudocolor because it saves memory, and speeds up the application, with no downside.
Mostly though, none of your business! You're job is to develop applications to the customer's needs, not set the customers needs. You can either write an application that plays well with others, or write an application that forces unneeded complications on the user, as the examples above do.
You may think that your application should always use one visual or another. For instance, you only need four colors, why not always use Pseudocolor if available? Well, the user may have some colormap hog that REALLY hogs every available color, and so they want your application to run in truecolor, so that this other application has free reign, even down to the last four colors, with the public colormap. Conversely you may feel your application should always use lots of colors when available. But a user may be stuck with a low-memory machine, and they'd rather deal with stippled images than an even slower computer.
For some arbitrarily large number (say 256), the reason for this is obvious. My choice of 16 may seem like a low number, but you not only have to play friendly with other friendly applications, you also have to play friendly with piggish applications that failed to support private colormaps.
Also, when a user does choose to run something in a private colormap, they typically don't do this to every application, only to one or two that really need it for their purposes. If your color-intensive application is most important to them, they may prefer to let it hog the colormap, while relegating other less important applications to private colormaps. Or vice versa. It's not your choice, it's theirs.
Colormaps get full. And some users simply hate private colormaps. So it's simply a matter that the colormap might be close to full when your application starts. So your application should do it's level best to find a way to run with whatevere it has available.
It's important to note that this should include studying the existing colors, and deciding if any of them are close enough.
Again, you may think your color-intensive application is really important. But someone else may think it is more important to keep the colormap from filling up, because of all the applications they have to run.
Command line options are great. But many tools are not launched from the command line, and in some cases a user may not be able to modify the menus used to launch a program. But they should be able to set resources to achieve the changes in behaviour that they need.
It's nice if users can change the behaviour without having to reload their resources.
Do you detect a theme in all of this? Users may not have the same hardware as you, and you should not try to dictate to them what hardware they have or how they have it configured.
Do you want people to use your software, or not?
|
Fine's Home
|
|
|
Send Me Email |