[Xr] Help: Render error on XrFormatRGB32
cworth at east.isi.edu
Sat May 3 05:28:46 PDT 2003
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.
Thanks for looking into this. Nobody has examined Xr performance at
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
> So Xr/Render seem to be much faster than Java2D in anti-aliased
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
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
USC Information Sciences Institute cworth at isi.edu
More information about the cairo