[Xr] Help: Render error on XrFormatRGB32

[Owen Taylor]

On Fri, 2003-05-02 at 18:15, Soorya Kuloor wrote:
> On Fri, 2003-05-02 at 15:15, Carl Worth wrote:
> > On May 2, Soorya Kuloor wrote:
> >  > I am a newbie trying to turn off anti-aliasing in Xr by trying to use
> >  > XrFormatRGB32 for the target suface (is this the right way to do
> >  > it)?
> > 
> > This won't quite do the trick for at least a couple of reasons:
> > 
> > 	1) Geometric objects, (strokes and fills), are pre-composited
> >            using an intermediate surface which is currently hard-coded
> >            to use XrFormatA8.
> > 
> > 	2) Eliminating alpha from the target surface affects more than
> >            antialiasing. It also prevents you from blending the
> >            surface with other surfaces, (eg. this is needed by the
> >            intermediate surfaces used in xrknockout).
> > 
> > So it looks like you'll need some other mechanism to get what you
> > want. Probably just a mechanism to control the depth of the
> > intermediate surface used for geometric objects.
> > 
> > Suggestions for an API.
> > 
> 
> With all the fiddling stuff I am basically trying to get a trade off
> between quality and rendering speed. The users of the package that we
> are building on top of Xr fall into 2 categories:
> 
> 1. Large number of 2D objects on the screen with lots of animations.
> These people want a lot of speed, but do not mind sacrificing quality,
> such as anti-aliasing and alpha.
> 
> 2. Not a large number of 2D objects or not a lot of animations, but
> would like quality.
> 
> What would be nice is to have are a set of functions to set some
> parameters that would let the users select what they need, similar in
> spirit to XrSetTolerance/XrGetTolerance.

Non-antialiased rendering isn't going to be any faster than antialiased
rendering without a fair bit of attention to optimization; and if
you optimize antialised rendering, it can be pretty darn fast on
modern machines, even without hardware acceleration.

Also that to get *good* non-antialiased rendering, you may have
to use significantly different (and more complex) algorithms than
for antialiased rendering.

And application that was designed for AA can't be switched over
to non-AA without major visual damage, since to get decent
non-AA rendering, you have to pick your line angles very carefully.
So, options for non-AA rendering don't help "user has slow machine".

My opinion on this is that it's better to just concentrate on making
AA as fast as possible, and forget non-AA rendering. Machines
that aren't fast enough to animate hundreds of AA objects in
real time are on the back-slope of the computing curve; by
the time Xr is significantly deployed they will be rare, 
5 years into the life cycle of Xr they will be historical 
curiosities.

Regards,
                                                 Owen