[eq-dev] comparision with ParaView/IceT
liuning
The parallel rendering library used by ParaView is IceT(Image Composition Engine for Tiles). The size of IceT source code is very small(about 260KB) and it is very robust. But the size of Equalizer source code seems to be a little large. I wonder if Equalizer provides some extra functions that are not included in IceT. So why Equalizer takes up so much space?
-Ning
Stefan Eilemann
On 18. Jan 2010, at 7:47, liuning wrote:
> The parallel rendering library used by ParaView is IceT(Image Composition Engine for Tiles). The size of IceT source code is very small(about 260KB) and it is very robust. But the size of Equalizer source code seems to be a little large. I wonder if Equalizer provides some extra functions that are not included in IceT. So why Equalizer takes up so much space?
IceT is -afaik- a compositing library.
Equalizer consists of
- a compositing library
- a task de-compositing engine
- a resource management system for run-time configuration and load-balancing
- a distributed, versioned object layer
- and much more ;)
HTH,
Stefan.
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
purpleKarrot
I beg your pardon for digging up this zombie thread, but there is something
that
came to my mind about this.
IceT consists of
- the core library
- a communication library
- a bunch of composition strategies
All parts are easily exchangeable. E.g. the default communication library is
built on top of MPI, but you can also use your own communication library.
Equalizer consists of many more features, but they are all tightly coupled
together. There is no "pay as you go" option. If you are looking for a
distributed, versioned object layer without a compositing library, look
further;
Equalizer does not provide the right solution.
To me this "and much more ;)" does not sound like a feature, but as a design
flaw.
Should we address this? Should we disintegrate Equalizer into independant
and most notably *reusable* subprojects? Their usefulness is beyond
question!
Cheers, Daniel
--
View this message in context: http://software.1713.n2.nabble.com/comparision-with-ParaView-IceT-tp4412173p5538272.html
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
Stefan Eilemann
On 16. Sep 2010, at 14:35, purpleKarrot [via Software] wrote:
> IceT consists of
> - the core library
> - a communication library
> - a bunch of composition strategies
>
> All parts are easily exchangeable. E.g. the default communication
> library is
> built on top of MPI, but you can also use your own communication
> library.
>
> Equalizer consists of many more features, but they are all tightly
> coupled
> together. There is no "pay as you go" option. If you are looking for a
> distributed, versioned object layer without a compositing library,
> look further;
> Equalizer does not provide the right solution.
>
> To me this "and much more ;)" does not sound like a feature, but as
> a design
> flaw.
>
> Should we address this? Should we disintegrate Equalizer into
> independant
> and most notably *reusable* subprojects? Their usefulness is beyond
> question!
Our current roadmap is:
1) Finish the API clean up for 1.0 and release it.
2) Refactor the eq::net API and library.
Right now I'm stuck in 1). You'll notice a lot of @version 1.0 tags in
the doxygen comments, which mark the 'official', stable 1.0 API. I
have to finish this task for the remaining classes in lib/client,
either by marking them @internal or @version 1.0.
The compositing strategies are separated in eq::Compositor. It makes
sense to refactor this, allowing for:
- easy integration of other compositing libraries (ParaComp, NVidia
CompleX, Ice-T)
- run-time, application-specific compositing
- Download-plugin-specific data types
I haven't spent much cycles on this yet.
You will notice that it should be very easy to build a eq::net dll,
since there are no dependencies for eq::base and eq::net to the higher-
level stuff in lib/client and util. The API itself needs some
refactoring, e.g.:
- Fall-out from RFE 2809019: Specify connection from a config file
when using appNode
- I'm contemplating using UUIDs as object identifiers. This ultimately
eliminates the need for net::Session
Furthermore there is the handling overhead in have many separate
shared libraries. Ideally I'ld like to have a build option to build
one Equalizer DSO or separate sub-DSO's.
I'm not sure what your intent is in starting this discussion, but if
you'ld like you can start working on the compositing stuff or point 2)
by prepping the build system and starting to add doxygen comments and
proposing concrete refactorings you deem useful. In any case, we'll
eventually get to it as well.
Cheers,
Stefan.
View this message in context: Re: comparision with ParaView/IceT