Re: [glean-dev] RFC: dsconfig matching changes

[Allen A. <ak...@ar...>]

On Tue, Dec 08, 2009 at 06:54:40PM -0700, Brian Paul wrote:
| In the case of readpixPerf, we only filter for rgb visuals.  Buf if 
| the visual also has Z (or stencil) we do extra tests (and produce 
| additional test results).  So, the ``A'' config and ``B'' config list 
| were loosely filtered, but the test results are tied to specific 
| configs.  The 'looseness' of the match() function causes us to compare 
| results from disparate configs.

I guess I would have separated the tests -- one for color buffers, one
for depth buffers, one for stencil buffers, and so on.  Not only would
that have solved the match() problem, but it would have allowed other
tests to depend on exactly the subset of readpixPerf tests that they
need.

But that might not be expedient at this point.  So one thing that really
makes sense to me is to ensure that exact matches take precedence over
any partial match.  That ought to cover all the most common cases.

| Right.  But when the XIDs match AND ALL the other fields match, the 
| configs should be identical (and the results comparable), even if the 
| results come from different machines/drivers.

If ALL the other fields match, then the XID doesn't matter, right?  The
configs should be identical from the GL's point of view?

| But in the case where there's many configs with identical fields, but 
| different XIDs, the equal() test should consider the XID.
| 
| With GLX, for example, we can have two visuals which have identical 
| attributes but one is TrueColor and the other is DirectColor.  The 
| DrawingSurfaceConfig code doesn't consider visual classes.  This is 
| where matching the XID is good.

If that really matters, then maybe Visual class should be added to the
set of filterable attributes.  I don't think I ever encountered a system
where the distinction between DirectColor and TrueColor mattered to the
GL, but maybe there are examples nowadays.  I'm happy to defer to your
judgement there.

Allen