changed: - in former times all the rendering, context-management and window-managment was handled by [gemwin] this should change! (note: even though wiki supports history, i'd rather give several revisions of the ideas on one page at the same time, to see how they evolve) Revision 2: GemOutput: only handles the actual output: open output-device, generate openGL-context, associate device and openGL-context when "render"-message from [gemcontrol] is received, it only makes its own display "current" and calls-back. interaction with the devices (e.g. keyboard/mouse-input) is handled by this object (outlet) DOES NOT handle any "openGL-specific" things, like viewpoints, lighting, fog, background... (this is done by [gemcontrol]) [gemcontrol] "localized" via context "name" (symbol); name-association is handled globally, so [gemhead]s can hook to a name, even if no corresponding [gemcontrol] is made (yet); several [gemcontrol]s can be associated to the same name. local data (_not_ associated with the "name"): viewpoint, lighting, background,... ("openGL-things") context data (associated with the "name"): which gemlists to execute global data: none pro: no global data; "context"s but fully backwards-compatible (with default namespace "") contra: no solution yet for lighting problem: what about timing ?? if each [gemcontrol] had it's own timer, how do we sync different [gemcontrol]s together (e.g. if we want a CAVE with 6 views of one scene in sync!) solution: think of something with an external sync-source, like a BANG "example patch revision 2":img:example2.gif Revision 1: [gemcontrol] manages the static !GemMan, e.g. the render-tick several [gemcontrol]s manage the same! data, sending "1" to this [gemcontrol] will turn on rendering at the others too! sends out a "render"-message to all connected [GemOutput]s GemOutput handles an output-devices, e.g. a [gemwindow] interaction with the devices (e.g. keyboard/mouse-input) is handled by this object (outlet) methods to change dimension, background, viewpoint of the GemOutput (as far as this is possible: e.g. ieee1393-output might not be able to change the dimension of the image and has no "offset") receives a "render" message from [gemcontrol], makes its openGL-context "current", set's up the viewport and calls the gemcontrol::render(), which in turn executes the [gemlist]s can be instantiated multiple times ("multiple windows") pro: separation between global render-chain and "local" output-devices; multiple windows (with different views,...) contra: why is the render-chain global ? window-handling and viewport-handling is something very different: think of further splitting