[PD-dev] [GEM] rendering context (gem2pdp)

[Daniel Heckenberg]

After a bit of digging into the word of Device contexts (DCs - Windows
Drawing surface more/less) and Rendering contexts (RCs - openGL) this seems
to be the state of play (on Windows at least):

- textures can't be shared between rendering contexts
- display lists can be shared between rendering contexts
- a single DC can have multiple RCs (with only one active at a time)
- Multiple DCs can be used with a single RC as long as they have the same
pixel format (only one DC, RC pair active at a time)
- RC switches are slow
- DC switches are fast
- There are pixel formats (and hence DCs) which support accelerated, double
buffered, openGL display and pbuffer output (at least on nVidia hardware)

So hopefully we should be able to use a single RC for all rendering in GEM,
with a DC for each output window or pbuffer.  This should allow display
lists and textures to be used on any output window without duplication.

Of course, there are reasons why you might not like to do this - pbuffer
formats different to the display format could be useful.

Is the above all true/make sense?  What's the situtation with agl and glx?

Daniel


On 14/3/03 8:39 AM, "Daniel Heckenberg" <daniel at bogusfront.org> wrote:

> 
> Hi Tom, list,
> 
> This looks like great work.  I was hoping to have a look at some multiple
> rendering context stuff this weekend so I'll let you know how that goes.
> 
> An open question: does SDL encapsulate enough glx/wgl/mac os features to
> support pbuffers and multiple rendering contexts in a platform independent
> way?
> 
> Daniel
> 
> ----- Original Message -----
> From: "Tom Schouten" <doelie at zzz.kotnet.org>
> To: <zmoelnig at iem.at>; "Daniel Heckenberg" <daniel at bogusfront.org>
> Cc: <pd-dev at iem.kug.ac.at>
> Sent: Thursday, March 13, 2003 9:16 PM
> Subject: Re: [PD-dev] [GEM] rendering context (gem2pdp)
> 
> 
>> On Wednesday 05 March 2003 09:17, zmoelnig at iem.at wrote:
>>> Zitiere Daniel Heckenberg <daniel at bogusfront.org>:
>>>> How about this:
>>>> - you can name a rendering context in each gemhead and have that
>>>> rendering
>>>> chain render to the context (be it a window, pbuffer or whatever).
>>>> 
>>>> -Each gemwin can also be named.
>>> 
>>> hi daniel, et al.
>>> 
>>> my plan (which might be influenced too much by other 3d-rendering
> software)
>>> was rather not make completely independent rendering-chains (by naming
> them
>>> and connecting them via the name to a gemwin) but use the [gemhead]s
>>> rendering- chains globally connected to multiple [gemwin]s.
>>> The [gemwin]s could be controlled independently with respect to
>>> camera/viewpoint, bg-color, size, but also offscreen-rendering.
>>> This is really heavily influenced by the "camera"-idea of other
> software.
>>> 
>>> but on the other hand it is a lot of work to be done
>>> 
>> 
>> 
>> hi daniel, iohannes
>> 
>> i decided to do some more experiments with opengl stuff on top of pdp, and
>> this seems to work rather well. it is all centered around render context
>> packets being passed around. if you are interested you can have a look at
> the
>> opengl/ folder in the pdp package. maybe gem could benifit from this,
> dunno..
>> 
>> http://zwizwa.fartit.com/pd/pdp/test/pdp-0.11-test-6.tar.gz
>> 
>> it requires glx 1.3 though for pbuffer support. (the only things on linux
>> that have this that i know of are the 41.xx nvidia drivers and mesa 5.0)
>> 
>> right now all the rendering is to a pbuffer. there is a 3dp_context object
>> that provides a context and all 3dp_ objects draw to/manipulate this
> context.
>> 
>> on output, the contents of the buffer is dumped into a texture and
> displayed.
>> i chose this approach to have an easy multiple stage rendering chain,
> where a
>> pbuf can be dumped into a texture and reused in another pbuf rendering,
> etc..
>> this also allows to set the window dimensions independently from the
> render
>> buffer dimensions.
>> 
>> i also tried multiple camera views in two different windows, which works
> if
>> you propagate 2 different contexts trough a single rendering chain, and
> route
>> trough a different modelview transform chain in front of the main chain
> and
>> to a different window after the chain. (check the patches in test/).
>> 
>> one note: i have the impression that the rendering context switching
> (between
>> different pbufs and window for example) is a rather expensive operation. i
>> haven't nailed it down yet, but something is causing a lot of extra
> cycles..
>> 
>> two note: i don't think i understood context sharing very well. it seems
> you
>> need to explicitly share every pbuf with every other to get them to see
> each
>> other (for copying). now everything is shared from a single mother scratch
>> pbuf.
>> 
>> mvg
>> tom
>> 
>> 
> 
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
> 
>