There are no official
(py)gtkglext win32 builds available from gnome, trying various binary builds always leads to the same problem:
(python.exe:2224): GdkGLExt-WARNING **: cannot select DIB (python.exe:2224): GdkGLExt-WARNING **: cannot create GdkGLPixmap
See ticket:147#comment:22 The problem is that all of those binary builds are well out of date - and completely undocumented. Not at all helpful for debugging things.
So we need to build from source, either:
ming32 native build Unless otherwise stated, the configure step generally looks like this:
./configure --prefix=/mingw --build=mingw32
--disable-gtk-doc added if possible.
zlibcan be built from source (with the caveat from the instructions above about
glibhave a binaries from gnome (yuk)
glib) since the binary archives are missing the pkg-config file... (and hacking one by hand is just asking for more trouble)
atk. We can use more gnome binaries for this..
gtkglextand you cannot find an official one for win32 anywhere, and building from source obviously fails too - oh joy. And so the "recommended" way (judging from some mailing list posts) of dealing with this is to install a fake one - I'm not joking, see gtk-doc-stub. (again totally undocumented, even there)
gtkis not installed... sure it is. That's because
pango's pkg-config files aren't installed. So you must build
pangofrom source to get them.
pangofrom source, it complains that
glibisn't the right version. And it isn't. That's because the binaries are well out of date. So now we have to build
glibtoo, despite using binaries in the first steps.. (oh well, at least we have
glib, we need
libffi, and as mentioned above, the binaries are incomplete, so we have to build that from source as well (see How to compile glib using MingW under Windows) - alternatively, we could use those magic environment variables to tell it where to find
libffi- I didn't go down that route.
-march=i486" or later, but how? Well, through
CFLAGSof course (!):
export CFLAGS="-march=i686" ./configure --prefix=/mingw --build=mingw32 \ --with-pcre=internal --with-threads=win32 --disable-gtk-doc
(which makes me think we should probably build everything with the same
CFLAGS, oh well.. next time?)
GEN gdbus-example-objectmanager-generated.h /usr/bin/env: python2.5: No such file or directory make: *** [gdbus-example-objectmanager-generated.h] Error 127 make: Leaving directory `/home/XP_Pro/glib-2.35.3/gio/tests/gdbus-object-mana ger-example'
So it grabbed the wrong version of
Python and not the one we have installed (how could it..), and since
Python does not build on
MingW, we have to point it to the version we want it to use (and hope for the best when it comes to mixing compilers...):
export PYTHON=C:\Python2.7\Python.exe ./configure (...)
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ stdio.h:534:0, from cairo-missing.h:36, from strndup.c:31: c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/sys/types.h:118:18: note: previous declaration of 'ssize_t' was here make: *** [strndup.lo] Error 1
As per this mailing list post (which has a workaround)
Note: ideally, we would like to have
librsvg support, but this would also require building:
pangocairo (a cycle!?),
./configure --prefix=/mingw --build=mingw32 \ --disable-gtk-doc --with-gdktarget=win32
which then fails with:
font-pangoft2.c:14:28: fatal error: pango/pangoft2.h: No such file or directory compilation terminated. make: *** [font_pangoft2-font-pangoft2.o] Error 1
Looks like we do need freetype after all, which must be built before cairo apparently..
Rant: why is this such a horrible mess?
ming32 cross build Useful link: Building GTK apps for MS Windows on Linux
RANLIBenv var does not help):
export PREFIX=/usr/i686-w64-mingw32/sys-root/mingw/ export TARGET=mingw32 export PKG_CONFIG_PATH=$PREFIX/$TARGET/lib/pkgconfig export PATH=$PREFIX/bin:$PREFIX/$TARGET/bin:/bin:/usr/bin export LD_LIBRARY_PATH=$PREFIX/$TARGET/lib export LDFLAGS=-L$PREFIX/$TARGET/lib export OBJDUMP=/usr/i686-w64-mingw32/bin/objdump export CC="/usr/bin/i686-w64-mingw32-gcc -mms-bitfields" export CXX="/usr/bin/i686-w64-mingw32-c++ -mms-bitfields" export CFLAGS="-O2 -march=i586 -mms-bitfields" export CXXFLAGS="-O2 -march=i586 -mms-bitfields" autoreconf -iv ./configure --host=i686-pc-mingw32 --prefix=$PREFIX/$TARGET make /usr/i686-w64-mingw32/bin/ranlib ./gdk/.libs/libgdkglext-win32-1.0.a make /usr/i686-w64-mingw32/bin/ranlib ./gtk/.libs/libgtkglext-win32-1.0.a make /usr/i686-w64-mingw32/bin/ranlib ./examples/.libs/libdrawshapes.a make
then we're stuck because there is no way to build python with mingw... although there are python 3.3+) only
And in any case, even with this latest build the pixbuf functions do not seem to work and none of the demos work properly either.. (artifacts, non window refresh, etc)
documentation found here: http://cs.geneseo.edu/~baldwin/ivipp/GTKBuildProcess.pdf
r2361 allows us to package all the
OpenGL bits, and fixes the win32 test for GL support (using a temporary window to get a context.. yuk).
Problem is that we still get:
2012-12-25 18:24:53,569 OpenGL Version: 1.1.0 2012-12-25 18:24:53,640 GL Extension GL_ARB_shader_objects unavailable 2012-12-25 18:24:53,660 GL Extension GL_ARB_vertex_array_object unavailable 2012-12-25 18:24:53,670 GL Extension GL_ARB_texture_buffer_object unavailable 2012-12-25 18:24:53,680 GL Extension GL_ARB_framebuffer_object unavailable 2012-12-25 18:24:53,690 GL Extension GL_ARB_map_buffer_range unavailable 2012-12-25 18:24:53,700 GL Extension GL_ARB_copy_buffer unavailable 2012-12-25 18:24:53,700 GL Extension GL_ARB_uniform_buffer_object unavailable 2012-12-25 18:24:53,710 GL Extension GL_ARB_draw_elements_base_vertex unavailable 2012-12-25 18:24:53,710 GL Extension GL_ARB_provoking_vertex unavailable 2012-12-25 18:24:53,720 GL Extension GL_ARB_sync unavailable 2012-12-25 18:24:53,720 GL Extension GL_ARB_texture_multisample unavailable 2012-12-25 18:24:53,730 GL Extension GL_ARB_blend_func_extended unavailable 2012-12-25 18:24:53,730 GL Extension GL_ARB_sampler_objects unavailable 2012-12-25 18:24:53,740 GL Extension GL_ARB_timer_query unavailable 2012-12-25 18:24:53,750 GL Extension GL_ARB_vertex_type_2_10_10_10_rev unavailable 2012-12-25 18:24:53,759 GL Extension GL_ARB_draw_indirect unavailable 2012-12-25 18:24:53,759 GL Extension GL_ARB_gpu_shader_fp64 unavailable 2012-12-25 18:24:53,769 GL Extension GL_ARB_shader_subroutine unavailable 2012-12-25 18:24:53,779 GL Extension GL_ARB_tessellation_shader unavailable 2012-12-25 18:24:53,789 GL Extension GL_ARB_transform_feedback2 unavailable 2012-12-25 18:24:53,789 GL Extension GL_ARB_transform_feedback3 unavailable 2012-12-25 18:24:53,799 GL Extension GL_ARB_ES2_compatibility unavailable 2012-12-25 18:24:53,799 GL Extension GL_ARB_get_program_binary unavailable 2012-12-25 18:24:53,809 GL Extension GL_ARB_separate_shader_objects unavailable 2012-12-25 18:24:53,819 GL Extension GL_ARB_vertex_attrib_64bit unavailable 2012-12-25 18:24:53,819 GL Extension GL_ARB_viewport_array unavailable 2012-12-25 18:24:53,829 GL Extension GL_ARB_base_instance unavailable 2012-12-25 18:24:53,829 GL Extension GL_ARB_transform_feedback_instanced unavailable 2012-12-25 18:24:53,839 GL Extension GL_ARB_internalformat_query unavailable 2012-12-25 18:24:53,849 GL Extension GL_ARB_shader_atomic_counters unavailable 2012-12-25 18:24:53,849 GL Extension GL_ARB_shader_image_load_store unavailable 2012-12-25 18:24:53,859 GL Extension GL_ARB_texture_storage unavailable 2012-12-25 18:24:53,869 GL Extension GL_ARB_clear_buffer_object unavailable 2012-12-25 18:24:53,869 GL Extension GL_ARB_compute_shader unavailable 2012-12-25 18:24:53,869 GL Extension GL_ARB_copy_image unavailable 2012-12-25 18:24:53,901 GL Extension GL_KHR_debug unavailable 2012-12-25 18:24:53,921 GL Extension GL_ARB_framebuffer_no_attachments unavailable 2012-12-25 18:24:53,921 GL Extension GL_ARB_internalformat_query2 unavailable 2012-12-25 18:24:53,921 GL Extension GL_ARB_invalidate_subdata unavailable 2012-12-25 18:24:53,940 GL Extension GL_ARB_multi_draw_indirect unavailable 2012-12-25 18:24:53,950 GL Extension GL_ARB_program_interface_query unavailable 2012-12-25 18:24:53,960 GL Extension GL_ARB_shader_storage_buffer_object unavailable 2012-12-25 18:24:53,960 GL Extension GL_ARB_texture_buffer_range unavailable 2012-12-25 18:24:53,970 GL Extension GL_ARB_texture_storage_multisample unavailable 2012-12-25 18:24:53,970 GL Extension GL_ARB_texture_view unavailable 2012-12-25 18:24:53,980 GL Extension GL_ARB_vertex_attrib_binding unavailable 2012-12-25 18:24:53,980 GL Extension GL_ARB_fragment_program unavailable 2012-12-25 18:24:54,000 Error loading OpenGL support: \ ** OpenGL initialization error: OpenGL output requires glInitFragmentProgramARB Traceback (most recent call last): File "xpra\client.pyc", line 95, in <module> File "xpra\gl\gl_client_window.pyc", line 11, in <module> File "xpra\gl\gl_check.pyc", line 76, in check_support ImportError: ** OpenGL initialization error: OpenGL output requires glInitFragmentProgramARB ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2012-12-25 18:24:56,674 Attached to tcp:192.168.1.100:10000 (press Control-C to detach)
despite the extension being available according to various tools (ie: GPU Caps Viewer)
And unfortunately this is not a packaging issue as running the code directly from the clean python tree (with latest
PyOpenGL version 3.0.2) produces the same error.
Also, this is not a
pygtkgl issue either, as this error comes straight from
pyOpenGL... Here is the code in question (found in
EXTENSION_NAME = 'GL_ARB_fragment_program' (...) def glInitFragmentProgramARB(): '''Return boolean indicating whether this extension is available''' return extensions.hasGLExtension( EXTENSION_NAME )
hasExtension check does:
AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split() (...) result = specifier in AVAILABLE_GL_EXTENSIONS
Which is odd, it doesn't do anything fancy in there so you would think it should get the same list that other applications are quite happily getting? Calling
glGetString( GL_EXTENSIONS ) returns nothing, so something fishy is going on there.
And no, bypassing this check does not help, it just fails a little later when trying to use the extensions which does not exist..
The docs aren't particularly helpful here.
We don't need GL v1.3 as per r2363, the extension we need may still be available when the driver advertises GL v1.1 - so we revert that and also improve error display/handling in r2368.
We now also include
OpenGL_accelerate, see r2369
It seems that the
easy_install way of installing
PyOpenGL binary installers instead (or build from source - apparently, not tested that).
The only way I could find what
DLLs are needed is to grep the source, and then I found in
%s.%s" defined as "
sizeis obtained from
platform.architecture().strip( 'bits' )so it should be 32 or 64
vc compilervalue is either vc7, vc9 or vc10 based on some magic
sys.hexversiontests (so it should match the version of Visual Studio used for building python).
They are all there now, but it doesn't help. But then again it didn't complain when those weren't installed either...
When I run
xpra/gl/gl_check.py I get:
VirtualBox(with accelerated 3D drivers and dozens of extensions reported by
GPU Caps Viewer), I only get:
GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture
VMWare: identical to virtualbox...
PyOpenGL see more extensions on Windows??
Simply switching the gl context to double-buffered (done as part of r2370) allows windows to get full GL capability, and so we do finally find the extension we need... only to crash hard later :( (and when I say crash hard, more often than not it will take the whole virtualbox VM with it)
I think it causes memory corruption on win32 - see #229
with this patch, win32 works ok, for x264/vpx at least, but linux crashes..
Ignore comment above, the patch does not work :( It fails to import something which must be packaged differently and reverts to non-opengl rendering.. which has always worked ok.
may re-visit this for 0.9 with mingw on Fedora if someone packages gtkglext (maci?)
Most of the problems reported in this ticket are due to the context and the use of single vs double buffered, and many of the examples you can google will fail because of this.
All the errors are very misleading. This ticket should be closed as it is more of an already solved packaging/setup issue.
Anyone reading this looking to solve the same problem, see r2370 and in particular:
display_mode = (gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | gtk.gdkgl.MODE_DOUBLE)
And the fallback:
display_mode &= ~gtk.gdkgl.MODE_DOUBLE
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/227