[Xr] Help: Render error on XrFormatRGB32

[Carl Worth]

On May 2, Soorya Kuloor wrote:
 > 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.

Soorya,

Thanks for looking into this. Nobody has examined Xr performance at
all before.

I'm curious, what was the tolerance setting in Xr? I'd be very
interested to see how the Xr performance relates to changes in the
tolerance value.

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

That's encouraging since the code in Xr has just been written for
functionality so far --- there hasn't been an effort to go back and
optimize anything yet. I'm glad to know that we haven't done too much
that is obviously brain damaged.

 > 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?

As usual, profiling is needed before optimization can begin. I'm a bit
out of the loop in terms of current profiling tools, (though I've used
gprof in the past). Any recommendations from others on good profiling
tools?

A priori, I've got three ideas for possible optimization, (ordered by
stages in the graphics pipeline, not by potential benefit):

	1) During the stroke operation, the path is converted to a
           list of trapezoids. There is an O(N**2) algorithm in here
           that we should be able to make O(N). I can provide more
           details if someone is interested in looking at that, (and
           if profiling indicates it would be beneficial).

	2) We want to change the specification/implementation for the
           process of scan converting each trapezoid. We've got a plan
           for a new specification, but we still need an efficient
           implementation. Keith probably has the latest ideas here.

	3) Obviously, moving as much as possible off the CPU and onto
           the graphics hardware has tremendous potential. For X, that
           means accelerating the Render extension. Of course, this
           requires a particular skill set, (and knowledge of specific
           hardware). For other Xc targets, we can take different
           approaches. The idea of creating an OpenGL target for Xc
           has been proposed and might be an interesting project for
           somebody.

Thanks,

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                      cworth at isi.edu