I spent a bit of time looking at the wip/gdk-gl2 branch. In general, the public API looks very good to me - minimal but sufficient. I think the branch is basically good to land.
Performance on my system is actually quite poor in at the moment, which seems at least to be pathological interactions with the system (i915, Fedora 21, Haswell.) I see 60fps with the default configuration of gdkgears for any windowed size of the window, but when I maximize I see the frame rate drop to 30fps, and when I make it fullscreen, I see it drop to 10fps. 'perf top' shows kernel memory allocation as the top functions, so it may be that the continual allocation of new render buffers is triggering the problem. I also see rendering locked at a sub-multiples of 60fps - despite the fact that the rendering is additionally synchronized with the compositor frame clock. If I export vblank_mode=0 I see the expected non-locking behavior. * Docs for gdk_cairo_draw_from_gl() need to describe where the rendering ends up (0, 0 of the curent user coordinates, it seems) * Docs for gdk_cairo_draw_from_gl should document that it disturbs the current GL context. * It looks like there's a need to create a GdkGLContext for a window *before* the paint callback it is first used, since we use the existence of the internal paint GL context to know whether we are using GL for this paint; this is not documented. * Does the paint GL context need to be always derived from the toplevel or nearest native ancestor of a GdkWindow? It looks to me like things might not work right if gdk_window_create_gl_context() is called on a client side subwindow. * GtkGLArea tries to keep the context on unrealize() unless the screen changes; but this doesn't seem workable - first because of the need of the context to be created sharing with the internal paint context in GDK, and second because realize() doesn't actually check if the context already exists. * The approach of continually creating the render buffer may not give good enough performance, but if we do that, it's definitely desirable to create a minimal sized render buffer instead of one that's the size of the widget, since the cost of allocating a buffer gets larger the more pages that have to be allocated. * What's the intended event handling for GtkGLArea? It seems like you'd have to put it into a GtkEventBox and handle events on the GtkEventBox - maybe GtkGLArea should have an event window? * The name gdk_gl_context_flush_buffer() is confusing to me - end_frame() might be better. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
