Re: Should there be one renderer for each view?

[James W. W. <ja...@wr...>]

Dair Grant <da...@re...> wrote:

>James W. Walker wrote:
>
>>I wasn't asking about multiple renderers on one view, but rather
>>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


I don't see how that could work in Quesa as is, since the IR stores 
the GL context pointer in its instance data.  It's going to lose the 
GL context for A or B.


>>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.

One problem is that one GL context cannot share with all others, 
e.g., a pixmap context can't share with a window context, and if two 
windows are on monitors handled by different video cards, then I 
don't think they can share with each other.  So there would have to 
be multiple texture caches.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>