|
From: Dair G. <da...@re...> - 2004-11-14 22:10:12
|
James W. Walker wrote:
>I wasn't asking about multiple renderers on one view, but rather=20
>multiple views on one renderer.
Ah, OK. I don't think that will have been a restriction before, although
I suspect things wouldn't have worked if two views were submitted to at
the same time.
I.e., if two views both share a renderer then this will work:
start rendering to view A
submight objects to view A
finish rendering to view A
start rendering to view B
submight objects to view B
finish rendering to view B
But this won't:
start rendering to view A
start rendering to view B
submight objects to view A
submight objects to view B
finish rendering to view A
finish rendering to view B
Renderers are probably going to want to store some per-rendering-loop
state in their instance data (e.g., batching up transparent triangles)
that would break in this case.
You could make it work of course - renderers would just need to separate
their "this is my state" vs "this is my rendering state", and have the
latter stored in an array indexed by the current view or something...
>I don't actually want to do that. I've been thinking about possible
>solutions to bug 902975, "Use shared texture namespace". If I could
>assume that there is a one to one correspondence between views and
>renderer, it would make the problem a little simpler.
Could we just keep a proxy GL context around at all time? That seems to
be the approach they're talking about in QA1031 - something like:
- texture manager creates a fake gl context on demand
- texture manager creates/updates gl textures for qd3d textures
- renderer creates contexts that are shared with the TM context
- texture manager disposes of fake gl context on shutdown
Problem is the texture manager object needs to existing independently of
the renderers - not sure what the best way to handle that is, perhaps
when the renderer library is loaded/unloaded so that it's always around
even as individual renderers come and go.
-dair
___________________________________________________
mailto:dair+refnum.com http://www.refnum.com/
|