[Xr] Help: Render error on XrFormatRGB32

[Owen Taylor]

On Fri, 2003-05-02 at 19:54, Soorya Kuloor wrote:

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

Note that for GDI+ and I think Java2D too, when you turn off antialiased
rendering, you go through a completely different code path and take
advantage of the 2D hardware acceleration in the graphics card. This
isn't appealing to do for Xr:

 - You have to accept a high-degree of device dependence
 - You probably have to introduce concepts into Xr that simply aren't
   there right now, like "lines" as distinct from polygons.
 - If you want to take advantage of hardware acceleration on X,
   you have to make sure that your definitions can reduce to the
   X drawing model, with the warts of the X drawing model like
   the famous ugly-thick-lines problem.

And you have to make sure that you are doing benchmarks that reflect
application usage; I wouldn't be surprised if GDI (and X) can draw
non-antialiased 1 pixel lines hundreds of times faster than Xr,
but unless line drawing is a bottleneck real applications, that's
not a relevant benchmark.
 
> 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.

Well, profiling would be needed to know where the bottlenecks are
(if you wanted to provide your benchmark in C, that could be useful)
but my guess is that is that it is just is in the compositing routines.

And there is plentiful opportunity for optimizing that in libic - I look
a IcCompositeSolidMask_nx8x8888, which I think is the main compositing
routine for drawing solid shapes: it is special cased, which is good,
but it still makes a function call per pixel. Previous experience with
similar routines suggests to me that the speed could be doubled in C,
and at least doubled again by using MMX.

Regards,
                                            Owen