On 12/23/11 2:54 AM, Stefan Eilemann wrote:
> Since I cant comment on a closed bug, I'll do it here:

<sigh>  I apologize for the lameness of the SourceForge bug tracker.
"Close comment posting" is unchecked, so I'm not sure why it isn't
letting you comment.  In theory at least, it should still be open for
comments, even though it's closed.


>> Closing, since my understanding of the issue is that it's intended behavior
>> in VirtualGL, but please feel free to add comments if you have further
>> insight or if my understanding is incorrect.
> 
> Agreed: A useful, if feasible, extension to this heuristics would be to 
> postpone the decision to the first glXMakeCurrent of a context to a visible 
> window, and using this display connection to choose the compressor. I can't 
> guarantee an order since all GPUs are initialized in parallel, but only one 
> of them (node:10.0) uses a visible window (see other thread). The FBO 
> offscreen renderers also need a window for context handling, but these 
> windows are not mapped.

It already does that.  The first call to glXMakeCurrent() with a window
ID should cause VGL to pick a default image transport.  The default
image transport is set in the constructor of pbwin, based on the Display
* passed to glXMake[Context]Current().  pbwin is instantiated within the
body of glXMake[Context]Current() if a window is passed to that function
and the window does not already have a pbwin instance attached to it
(which is the case if that window has not been made current before.)
However, if you're calling glXMakeCurrent() on non-visible windows
(why?), then that would explain the behavior you're seeing.

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Reply via email to