Need Performance Comparision To 'AGG'

[stuseven]

. after reading your post, it occurred to me that something like what you're asking about actually did appear quite a while ago, when Xara first announced starting the Linux branch.
It was just a simple bar chart... on one side was a bar supposedly representing the speed of some other program, and on the other side... you had to scroll up to see the top... was the Xara speed bar - ten times taller. So there you have it... Xara is at least 10 times faster :-)

Hi Soquili.
Thank you for your response.

Hi guys,
The point is I'm a developer and the web page mentioned above shows the rendering speed of the several graphical engines. Now, I'm at the point of choosing the fast rendering engine for my needs. The AGG is the very powerful and fast open source library that allows developers to create stunting vector drawing programs. The AGG is as famous as the Cairo library is. So, why not to compare them both? The Xara CDraw engine is the alternative for me but before I choose I want to know the performance comparision. I do not want to clone or create a program similar to XaraXtreme. I just need this for my personal needs.

Best wishes and regards.

[rbirkby]

Another topic of note is that the CDraw that will be opensourced might be slightly different than the version that's used for Xara on windows, as that version has some portions coded in Assembler, but the version used by the linux Xara is C for portability.

So, if the version that they opensource is the full C version, it will be a bit slower than the windows Xara (which is I think the version mentioned in the benchmarks on the Xara page).

In the begining, there was the Acorn Draw module. Then along came a guy called Gavin who decided to write an API compatible version of Acorn Draw module that was much faster. This was called GDraw and was purchased by Xara (CC) for their Artworks product.

When Xara were writing Xara Studio (the first version of what is now Xtreme), they took GDraw (written in ARM assembler), passed it through a home-grown ARM->x86 assembler converter and out the other side came an Intel DLL, also called GDraw.

Now, from this, you could suppose that CDraw is really GDraw passed through a homegrown x86->C converter and that the reason CDraw has taken a long time to be open sourced is that the code is horrible, being machine generated, and someone deep in the bowls of Gaddesden Place is beavering away trying to tidy it up. Of course, I could be extrapolating too far and it could be the case that Xara have written a brand new C-based graphics engine that happens to perform about the same speed as their assembler engine....

[rbirkby]

For more background on GDraw, read
http://groups.google.co.uk/group/com...2fb2f3c?hl=en&

[fjgaude]

For more background on GDraw, read
http://groups.google.co.uk/group/com...2fb2f3c?hl=en&

Well, with CDraw as fast as it is on Linux I don't think many folks care how untidy the Assembler to C/C++ code might be. It works and there's nothing close to it in rendering speed on Linux or even Windows. It's simply ahead of its time: thanks be to whomever has had the vision to make it so.

Thanks to you for the history...

frank

[Odat]

Now, from this, you could suppose that CDraw is really GDraw passed through a homegrown x86->C converter and that the reason CDraw has taken a long time to be open sourced is that the code is horrible, being machine generated, and someone deep in the bowls of Gaddesden Place is beavering away trying to tidy it up. Of course, I could be extrapolating too far and it could be the case that Xara have written a brand new C-based graphics engine that happens to perform about the same speed as their assembler engine....

That's an interesting history, I did not know that! I got the assumption that there is a version of it coded in C from http://www.xaraxtreme.org/about/performance.html, which mentions that the benchmarks were done using the "platform portable C version of the Xara rendering engine".

If it's the case that the current code went ARM Assembler -> x86 Assember -> C, I certainly hope that the delay in the release of the code is someone doing some serious cleaning up of things.