From: Gus <gus@zip.com.au>
  To  : ggi-develop@eskimo.com
  Date: Wed, 10 Feb 1999 15:57:15 +1100

(longish) various problems with existing ggi3d

as it stands:

(1) a module can only get at one source of information: that passed to
it from the module immediately upstream

(2) a module can only have one output

(3) flow of execution either comes back to the parent module (eg:
first_mod(&in, &out1); second_mod(&out1, &out2); etc) or the modules
call each other -- its a mixture of both at the moment


problems:

because we are assuming that you only connect modules with matching
interfaces, (1) means that each module must pass downstream _all_
information required by later modules. thats just inefficient,
inflexible and plain silly.
(because of (3), you could have libggi insert extra info at points, but 
that means that libggi3d must have a knowledge of interfaces (bad))

(2) and (3) mean that it is impossible for a module to start multiple
threads downstream -- something which i think is a strong point for the
libggi3d module + opaque interfaces idea.

(3) means that free()ing of interface data structures, etc sucks. you
either have to have another callback into the module that created the
structure, or let libggi3d know how to free each structure (which
isn't going to happen)



proposals (independent):

(a) instead of thinking of it as a pipeline, or a flow of data, think
of each module as requiring some pieces of data and generating others.

libggi3d becomes a "database" for getting at this data, and ensuring
that each module's requirements are met by the time the module is
called

this allows the final module to get at some data from the first module 
without any of the intervening modules needing to care

i'm not sure whether the data should be passed as parameters to the
module, or the module should fetch it itself from libggi3d (possibly
get a pointer at module initialisation time to where the data will be
later?)

(ideally, a module would know if some of its generated data won't be
needed (and so doesn't generate it) (or would we just have finer
grained modules in this case?))

good:
no unnecessary data passed around

bad:
possible bloat as data hangs around longer than necessary (although
far less than having modules pass down unnecessary data, assuming that 
lower modules might need it)  (but see (b) below)

would need a way of ensuring that each module was getting the right
data structure (eg: threads with identical interfaces, but different
data (eg: those 3d goggles things))

dependency management would become harder, since there would be
(presumably) more of the same data structures floating around (eg: a
list of polygons) and more dependencies between modules  (but still
quite possible)


(b) enforce a system whereby each module calls the next one internally
ie:
module_do_stuff_now() {
  /* code */
  register_some_data_for_later_use() /* assuming (a) */
  do_next()
  /* cleanup */
}

good:
if a module feels like spawning threads then it would call do_next()
more than once (once in each thread) and libggi3d doesn't need to know 
about it

data can be allocated on the stack and passed to later modules that
way

interface data structures can be cleaned up easily and immediately

since data will only be needed downstream, the structures for (a) can
also do some funkiness with the stack (may avoid some threading
problems?)  (there's an interesting idea thats trying to get out here
- have to think about this some more)

bad:
would make pipeline "profiling" harder, since there isn't a common
point to return to.
(the do_next() function should be a hook/macro back into libggi3d,
where it can play with globals to get around this problem (although i
don't know what threads would do to this))

larger stack


thoughts?

(i'm not quite so happy about (b))


-- 
 - Gus

----- End forwarded message -----

-- 
 - Gus