Re: [Plib-devel] Re: [Fwd: Plib 2.0]

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:

>         I guess Steve's desire to fold PUI into SSG means that I am 
> going to have to learn SSG.

Well, here is the thought:

Let me talk about a hypothetical library 'X'.

X is a library that stores a tree structure of things.  Some things
are leaves of the tree, others are nodes that connect branches together.
There are two basic operations that X does on that tree - it walks
the tree in order to render it to the screen - drawing only the leaf
'things' that are visible.  Another operation is to traverse the scene
finding those nodes that are 'hit' by a particular geometric primitive.
Each of the leaf nodes has a bunch of properties that determine what
the node looks like - these include shape and colour, transparency...
perhaps other things too.

So far, 'X' could either be SSG or PUI.  SSG's leaf nodes are 'ssgLeaf'
classes, PUI's are 'puButton' and such.  SSG's branch nodes are 'ssgBranch'
classes, PUI's are 'puGroup' and such.  The mouse click testing in PUI
is a precise analog of the 'isect' traversal in SSG.  The business of
inheriting 'style' and colour/alpha in PUI is akin to the ssgState
management in SSG.

SSG has 'ssgSelector' nodes that indicate which (if any) of their child
nodes will be isect'ed or rendered.  PUI has a collection of enable/disable
flags that do similar things.

All in all, if we were starting from scratch, we would never have written
PUI and SSG as separate libraries.  They would have been the same library -
but perhaps with some 'wrappers' to make PUI look more like a GUI library
and SSG look more like a 3D renderer.

So, it seems to me that merging the two would be a natural thing to do.

There would be interesting benefits for PUI:

* PUI would gain the ability to use genuine 3D objects as GUI elements.
* You'd be able to use a 3D modeller to design and view GUI pages.
* PUI widgets could be textured, animated, moved around on the screen
   using the same techniques that allow those things to happen in SSG.
* PUI widgets could be applied to 3D objects - or the entire GUI page
   moved off in 3D.
* PUI needs to be moved from absolute screen coordinates to a more
   rational (screen-resolution independent) system.  That would just
   drop out of this change.

I can see lots of possibilities.

 >  One thing I do NOT want for PUI, though, is
> the baggage of all the file readers and writers.

Well, I suppose we could invest the time to make file readers and writers
load dynamically - but I'm not sure that's really necessary.

In an 'un-stripped' binary (ie with all of the symbol table in place),
SSG is 12Mb and PUI is 4.5Mb - that's the amount of extra disk space.

When you strip out the symbols (which gets you closer to the actual
in-memory footprint, SSG is 0.7Mb and PUI is 0.3Mb.

So the most that this 'baggage' is costing you is about 400kbytes.
To put that in context, that's about the same as a single font texture
in PUI.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----