Vista - RenderCapability::Tier returns 131072?

When I look at RenderCapability::Tier in my managed C++ app it returns
131072. Any idea what's going on? This is on XPsp2 with the latest WinFX
release. The code looks like -

int tier = RenderCapability::Tier;

Thanks-

John

Tier is in a Major.Minor format, with two bytes to each. So, tier 2.0 is (2
<< 16), which is 131072.

-Adam Smith [MS]

"John Dunn" <JohnDunn@discussions.microsoft.com> wrote in message
news:07B5DF5D-8B23-4781-955E-980B1C675ABA@microsoft.com...
> When I look at RenderCapability::Tier in my managed C++ app it returns
> 131072. Any idea what's going on? This is on XPsp2 with the latest WinFX
> release. The code looks like -
>
> int tier = RenderCapability::Tier;
>
> Thanks-
>
> John

Adam Smith wrote:

> Tier is in a Major.Minor format, with two bytes to each. So, tier 2.0
> is (2 << 16), which is 131072.

Why not make it a System.Version[1] instead of an int then? It would sure
make it easier to work with.

Curious,
Drew

[1] http://msdn2.microsoft.com/en-us/lib...m.version.aspx

A reasonable suggestion, but it's really not a Version per se, though
clearly it shares some of the same design issues. For example, the Build
property has no meaning here, and Major and Minor aren't "revisions". The
expectation is that users of Tier will either perform exact equality or will
compare "<" or "<=", etc, none of which require 'cracking' the number to
separate major or minor tiers.

-Adam Smith [MS]


"Drew Marsh" <drub0y@hotmail.no.spamming.com> wrote in message
news:f01844f1f86a28c868c74eed2660@msnews.microsoft.com...
> Adam Smith wrote:
>
>> Tier is in a Major.Minor format, with two bytes to each. So, tier 2.0
>> is (2 << 16), which is 131072.
>
> Why not make it a System.Version[1] instead of an int then? It would sure
> make it easier to work with.
>
> Curious,
> Drew
>
> [1] http://msdn2.microsoft.com/en-us/lib...m.version.aspx
>
>

Adam Smith wrote:

> A reasonable suggestion, but it's really not a Version per se, though
> clearly it shares some of the same design issues. For example, the
> Build property has no meaning here, and Major and Minor aren't
> "revisions". The expectation is that users of Tier will either
> perform exact equality or will compare "<" or "<=", etc, none of which
> require 'cracking' the number to separate major or minor tiers.

Yeah, excellent points... it's really not a version. I guess it's just awkward
having to shift the bytes around in the rich world of .NET. Perhaps a struct
that wraps up an int and offers two properties that do the shifting would
be nicer? Just thinking out loud, it's not really THAT bad, but I can see
a lot of people having to do this themselves to know what level of richness
to apply to their application based on the hardware capabilities.

Cheers,
Drew
___________________________________
Drew Marsh
Chief Software Architect
Mimeo.com, Inc. - http://www.mimeo.com
Microsoft C# / WPF MVP
Weblog - http://blog.hackedbrain.com/

I agree that shifting isn't fun, but I'm not sure how often people will even
care to extract the Major version.

I think that most people will do something like:

if (RenderCapability.Tier >= Tier1)
{
//nifty stuff
}
else
{
//fallback
}

where they will simply be comparing against a const instead of extracting
the specific major/minor.

-Adam Smith [MS]

"Drew Marsh" <drub0y@hotmail.no.spamming.com> wrote in message
news:f01844f1f86cd8c868d191359f3e@msnews.microsoft.com...
> Adam Smith wrote:
>
>> A reasonable suggestion, but it's really not a Version per se, though
>> clearly it shares some of the same design issues. For example, the
>> Build property has no meaning here, and Major and Minor aren't
>> "revisions". The expectation is that users of Tier will either
>> perform exact equality or will compare "<" or "<=", etc, none of which
>> require 'cracking' the number to separate major or minor tiers.
>
> Yeah, excellent points... it's really not a version. I guess it's just
> awkward having to shift the bytes around in the rich world of .NET.
> Perhaps a struct that wraps up an int and offers two properties that do
> the shifting would be nicer? Just thinking out loud, it's not really THAT
> bad, but I can see a lot of people having to do this themselves to know
> what level of richness to apply to their application based on the hardware
> capabilities.
>
> Cheers,
> Drew
> ___________________________________
> Drew Marsh
> Chief Software Architect
> Mimeo.com, Inc. - http://www.mimeo.com
> Microsoft C# / WPF MVP
> Weblog - http://blog.hackedbrain.com/
>
>