[Xr] Help: Render error on XrFormatRGB32

[Soorya Kuloor]

On Fri, 2003-05-02 at 16:43, Owen Taylor wrote:
> 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)?
> > > 
> > 
> > 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

I'd really like to agree with you Owen. However my use of other 2D
graphics packages (Java2D, GDI+) indicate otherwise. For example, if I
turn off anti-aliasing in Java2D I get approx. 7-8 times speed up
compared to anti-aliased rendering. Similar performance difference
exists in GDI+. May be their anti-aliasing drivers are badly written, I
do not know.

Just for info, I wrote a crude "benchmark" program that draws ellipses
to compare Java2D to my Java based Xr binding. I am running a Athlon
2100+ CPU machine with 1.5G RAM, Redhat 9, NVIDIA GeForce 2MX. Here are
some numbers:

Java2D: approx. 200 paints/sec with anti-aliasing, 1500 paints/sec
without anti-aliasing.

XrJava: approx 500 paints/sec with anti-aliasing.

I saw similar results drawing other shapes or combinations of them.

So Xr/Render seem to be much faster than Java2D in anti-aliased
rendering.

Xr needs to be atleast twice as fast as it is now to meet some of the
extreme speed cases that we see. May be some tweaking and optimization
will help.

Can I help in any way?

Thanks,
-- Soorya