Re: Some perspective from the cheap seats...

Around 18 o'clock on Mar 25, Mark Vojkovich wrote:

>   The bigger problems were things like repeat, which becomes
> difficult if the hardware doesn't support non-power-of-two textures,
> which, as far as I can tell still includes alot of hardware.
> Maybe Longhorn will change this.  I don't know.

2D apps still use repeated patterns for stuff, so it's hard to just throw 
that capability out.  Just as the current server can accelerate some tiles 
better than others, Render will likely run faster with repeated patterns 
of certain sizes.  Perhaps a QueryBestSize function should exist to let 
apps know what "good" sizes might be, but I think we've seen how little 
apps even bother asking.

>   Also the union of Drawable and Picture presents some problem.
> That's because many hardware don't support linear formats for
> textures or drawables, or if they do, they support them with 
> limited functionality.

I guess I'm confused by this -- the 'Picture' is just a way to wrap a 
drawable up with some rendering state and a mapping of pixel values to RGB 
values.  It doesn't imply any kind of linear access, of course if you do 
want to render with software, it will probably be easier if there's a 
linear mode available.

> I haven't looked at the transform stuff.  Is this just a
> transformation matrix applied to the texture coordinates?

Yes, it's just a projective transformation matrix.

> If so, that's probably OK, but it throws the precise rendering
> model out the window.  

As in other areas, Render provides for precise and imprecise rendering with
this operation, so apps that care about performance can simply choose a 
less well defined mode.

>   Overall I think the non rectangular geometry in render
> presents the biggest problem.  You're pretty much going to be
> rendering masks in software that you can pass to the hardware
> for composite. 

Even the polygons permit imprecise rendering where the alpha values can 
differ by a certain amount as long as the a few invarients are held. 
Any technique that is equivalent to some kind of oversampling should work 
just fine.

It may be that most applications end up using the imprecise mode; that 
really doesn't matter much as I have to have a software implementation 
anyways, and we might as well write down how it works so I can test it.  
Also, the imprecise polygons are defined in terms of maximum error from 
the precise spec, so they're pretty testable.

> Also, as mentioned there is a transition to floating point
> for framebuffer formats.  Big problems with the precise
> rendering model there.

Yup.  Again, we can specify a 'precise' mode which defines the center of
acceptable behaviour and then error bars around that to constrain 
implementations to reasonable behaviour.

One problem with the current core protocol is that imprecise behaviour is 
so badly specified that it's essentially untestable; placing an easily 
measured bound on imprecise behaviour should make it possible to verify 
all implementatiosn easily.

-keith