[1657] in Release_7.7_team
More on the default visual issue.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Feb 11 18:29:04 1999
Date: Thu, 11 Feb 1999 18:28:56 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: f_l@MIT.EDU, release-team@MIT.EDU, owls@MIT.EDU
Summary:
I thought finding the best visual was easy. It's not.
I thought writing code to improved upon the choice of the default visual
was straightforward. It's not.
I think maybe we should continue to ponder the consequences of going to
a 24bit default on some of our machines.
Detail:
I have done more study of the question, "What would it take to teach an
application to pick the best visual, if we assume that the default one
is not the best one?" (As inspired by Tom Grayson's ARCView issue. It
turns out that Squea, and EZ pick the visual in the same way.) The
answer is not as simple as I presumed in the epistle in which I offered
code. For example, the Sun Creator 3D graphics offers two 24 bit true
color visuals, one that is gamma corrected, one that is not. But the
Xlib protocol knows nothing of a gamma correction property, so one would
have to use a Sun-unique call to determine which was which!
So far, the best design I have come up with, looks not at the proffered
depths like the code I previously submitted, but consists of a
prioritized table of pairs: depth and visual class, and steps through
the table pair by pair until a match is found. But it is ideosynchratic
in the X configuration as to whether, for example, a gamma corrected or
non-gama-corrected visual would be the one used.
A *LOT* of judgement goes into picking the best visual. I am slowly
becoming a believer that it may well be reasonable to rely on the
DefaultVisual to name the best one. At issue here is that there are
many more possibilities for a platform-independent application to test
than I had first thought.
-wdc
