[Xr] XrMatrixGetAffine() function

[Soorya Kuloor]

Yikes, forgot to attach files.

-- Soorya

On Thu, 2003-07-03 at 14:19, Soorya Kuloor wrote:
> On Thu, 2003-07-03 at 12:16, Keith Packard wrote:
> > Around 12 o'clock on Jul 3, Soorya Kuloor wrote:
> > 
> > Thanks very much for your comments:
> > 
> > > * Text handling does not seem to be as good as the rest of the drawing,
> > > both API and speed-wise.
> > 
> > This is well known -- Xr is attempting to use Xft for text rendering and 
> > the result is quite horrible.  I'm hoping to get a chance to write down 
> > some ideas I've been mulling over to see if we can't start afresh and 
> > build something that better matches the Xr style and can be implemented 
> > efficiently.
> > 
> 
> Great to hear that. In real time SCADA type of displays (we are using Xr
> for this) text updates are done very frequently and we found that in Xr
> text drawing takes up a significant portion of the update time. So this
> slows down things.
> 
> > > Especially, the initial query for a given font-transform combination
> > > seems to take long time too (the call into fontconfig).
> > 
> > Pango caches the results to make future queries faster, but fontconfig 
> > itself is not likely to improve dramatically in the near future.
> > 
> > Drawing the text will get a lot faster as we get a chance to optimize the 
> > underlying compositing routines.
> > 
> > > * We did a speed comparison of Xr against GDI+. For the ellipse drawing
> > > test (posted by Owen) with anti-aliasing GDI+ is approx 2-2.5 times
> > > faster than Xr.
> > 
> > That's actually very encouraging -- none of the Xr rendering codepaths 
> > have seen any optimization at all, and the trapezoid filling code is 
> > already scheduled for a complete rewrite which should make it a lot 
> > faster.  Combine that with optimizations in the compositng code and the 
> > tesselation code and getting a factor of 2 in performance should be very 
> > easy.
> > 
> 
> Yes, I was surprised to see this too. I would have guessed GDI+ would be
> much faster than this with all the hardware acceleration MS might have
> put into it. However, these timings are just on one machine.
> 
> I also wrote a test program that strokes and fills 600 ellipses
> (attached below) and did a runtime profiling using valgrind. Here are
> the screenshots of the profiling info (obtained using kcachegrind). The
> first image cpuprof-1.jpg shows runtimes sorted based on self timing and
> the other based on cumulative timings. I could not make kcachegrind to
> dump to a file, so I am including screenshots. The test used an X server
> with Render extension (Redhat 9, NVIDIA accelerated driver with
> RenderAccel on).
> 
> Approx. 34.5% time is used by memcpy for sorting edge lists during
> tesselation. Speeding up some of these parts (as you mentioned above)
> for sure should sppedup Xr a lot.
> 
> -- Soorya
> 
> >
> > -keith
> > 
> > 
> > 
> > _______________________________________________
> > Xr mailing list
> > Xr at xwin.org
> > http://xwin.org/cgi-bin/mailman/listinfo/xr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xrbench.c
Type: text/x-c
Size: 8061 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/xrbench.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpuprof-1.jpg
Type: image/jpeg
Size: 148481 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/cpuprof-1.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpuprof-2.jpg
Type: image/jpeg
Size: 146051 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/cpuprof-2.jpg