Rendering Engine as standalone library

[NabilS]

Hi everyone,
I have heard about your great rendering engine, and I wanted to know if you could make it a standalone library, so that any Open Source Software who wants a great rendering engine can use it.

[remi]

Please bring in your knowledge in the Xara Xtreme LX project, instead of trying other things with their Rendering Engine. Don't you think so?

Remi

[abligh]

Hi everyone,
I have heard about your great rendering engine, and I wanted to know if you could make it a standalone library, so that any Open Source Software who wants a great rendering engine can use it.

It's currently a .a file (no source, today) in the build so to that extent it is a separate library. However, neither the ABI or the API are settled down yet, so it's not quite suitable for this at this stage.

It would be also good to have a shared library that renders .xar files. xarlib will give you a bitmap out of a .xar file (using our rendering engine) and you can use that today. It's not, however, currently suitable for general purpose rendering. Sorry.

Alex

[Charles Moir]

As I replied to a very similar thread:
CDraw on its own doesn't help create a stand-alone browser, as it's just the really low level, and very dumb, rendering engine. In order to create a stand-alone renderer that can take .xar files we need a much larger chunk of Xara Xtreme LX. However we do hope to create exactly this at some point. i.e. a simple library that can render .xar files, that could then be used by third parties for a number of things, such as browser plug-in, or stand-alone file viewer.

[NabilS]

The reason I asked this was that an ultra-fast rendering library would be useful to, for example, make an ultra-fast plugin for SVG, making it more of an alternative to proprietary formats.

I may ask another question: Do you use any assembly code in your library or is it plain C?

[Charles Moir]

We use assembly code in the Windows version, but the open-source (what will be the open source) version uses pure C. It's the only practical way if we want cross platform and multi-processor compatability.

[Xhris]

We use assembly code in the Windows version, but the open-source (what will be the open source) version uses pure C. It's the only practical way if we want cross platform and multi-processor compatability.

On similar hardware, does using C reduce the rendering performance of Xara relative to assembly?

[abligh]

On similar hardware, does using C reduce the rendering performance of Xara relative to assembly?

Yes. The hand coded assembler will always be faster than C compiler output. Equally, choice of C compiler makes a difference. Sadly, MSVC seems to do a better job than gcc. We hope the gcc people will be interested in doing some optimization here.

Alex

[Xhris]

Yes. The hand coded assembler will always be faster than C compiler output. Equally, choice of C compiler makes a difference. Sadly, MSVC seems to do a better job than gcc. We hope the gcc people will be interested in doing some optimization here.

Alex

When Xara LX is complete, will LX C become the standard over windows assembly when upgraded in the future? Or will both exist simultaneously? If cross platforming means that even the windows version will become a C port of the LX version, does this mean that the successor to Xtreme will see a reduction in performance?

[abligh]

When Xara LX is complete, will LX C become the standard over windows assembly when upgraded in the future? Or will both exist simultaneously? If cross platforming means that even the windows version will become a C port of the LX version, does this mean that the successor to Xtreme will see a reduction in performance?

Well I can't speak for Xara, but one assumes they would like to keep their current income stream, and making things run slower sounds like shooting themselves in the foot...

Note it's (pretty much) only the drawing library which is in optimized assembler on the Windows version, not the whole program.

Alex