Personal tools
You are here: Home development GemWiki GemcontrolGemoutput
Views

Edit history

Edit: -1 of 1
Time: 2006-12-20 12:40:27
Note: /pd/pd/portal_catalog/manage_catalogRebuild

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



Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser