GNOME.org
 

Re: [GtkGLExt] Sharing display lists + textures

Quoting lindleyf cox net:
Indeed, I've read elsewhere that list sharing causes those resources to become reference counted. That's useful. Furthermore, I ought to be able to use gtk_widget_create_gl_context() to create a context which doesn't get destroyed when the associated widget is unrealized (haven't tested it yet though).
However, there's still a problem. My scheme keeps things simple by never *actually* destroying figure windows. When a figure is closed, it is hidden, but kept around; when a new figure is requested, one of the previously closed ones may be opened and reused. This prevents things like queued redraws failing because they're trying to operate on widgets that no longer exist.
The difficulty is that the very first window *remembers* that I set its sharing parameter to NULL since I didn't have a context yet. So when that window is closed and then re-opened, the new context created on the second realize() will still have a NULL sharing parameter, even though by that point I may have other contexts around to share with. 


I am not sure hiding windows instead of destroying them is a good ideia...
Anyway, I would expect the GL context of a window to remain valid if the window is merely hidden, so the first time you create a window, you would just save the context returned and then use it to create new windows... in your case window 1 is always there so I would expect this to work just fine...
Of course you could create windows 1 and 2 in the beginning and then never use window 1, if you have trouble with the NULL parameter... but I think this is really unnecessary... perhaps you should rethink your design... 

Carlos
However, I can't simply call set_gl_capability() again to change the sharing aspect; it will fast-succeed when it detects it's already set. 

---- Carlos Pereira <jose carlos pereira ist utl pt> wrote:

I found this problem several weeks ago (I even complained on this list):
shared lists only worked fine when the first window was  still available.

Then I realized that it was indeed bad design of my own. You can create
and destroy as many windows as you like, including the first window, and
shared lists will work just fine, as long as you have always a valid
window at any given moment (even this limitation could be worked out I
believe, you would have to copy/save a valid GL context somewhere).

The trick is: when you create a new window, the context that you supply
to share the lists, must be the context of a window that exists at that
moment, not necessarily the context of the first window you created!

When you destroy the first window, its context cannot be used anymore to
serve as a model, when new shared contexts are created. You must always
supply a valid context, of a valid window! this works fine with all
shared lists I use. I never tried with textures but I assume it should
work the same way.

Specifically:
1) create window 1;
2) create window 2;  #shared lists work fine in windows 1 and 2
3) remove window 1;  #shared lists work fine in windows 1 and 2
4a) Wrong: create window 3 with context from window 1; #shared lists
will work on window 2 but not on window 3!
4b) Good: create window 3 with context from window 2; #shared lists work
fine in windows 2 and 3!

Best regards,
Carlos
> At first glance, GtkGLExt supports a simple interface for sharing display lists and textures, which is nice. However, when I actually try to use it, I've run into several practical problems and I was hoping for some advice on ways to solve them. 
>
> I have a GUI which can contain a list of items to be viewed, and zero or more figure windows in which to view them. I use GtkGLExt to draw the items in the figure windows using OpenGL. 
>
> For efficiency, there are some things (texture downloads, display list generation) which I'd prefer to only do once the first time something is viewed, and then just re-use, even if the item is displayed in a different figure window, so it makes sense to share display lists + textures between the contexts underlying each GtkDrawingArea. 
>
> I've figured out a way to do it....provided the first figure window stays open. All the other figure windows share with the context from there. But if that figure closes, then any windows currently existing seem to be all right, but new ones created later don't handle the textures properly. The closed windows are not actually destroyed, merely gtk_widget_hide()en, but merely unrealizing them seems to be enough to destroy the GdkGLContext. 
>
> I've long thought that the biggest design flaw in OpenGL is the difficulty of creating a context without a window to attach it to. If I could just create a "window-less" context then I'd be fine, but that seems to be quite difficult using the GtkGLExt interface. 
>
> So my question is, first, has anyone encountered this type of problem before? And second, what actually happens when I share textures/display lists? If I create a texture in context A, then tell context B to share with A, then destroy context A, then create context C and tell C to share with B----will that texture be available to C or not? 
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkglext-list


_______________________________________________
gtkglext-list mailing list
gtkglext-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkglext-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]