Issue #7 invalid

Render functions don't always work

Bil Bas
created an issue

Some of the render functions that are calling OpenGL underneath seem to work on about 50% of machines I've tested on. In failing, they just do nothing!

  1. Ubuntu 13.04 x64 - works (Nvidia 550 Ti)
  2. win7x32 VM (on the above Ubuntu machine) - works
  3. win7x64 - fails (Nvidia GTX560)
  4. win7x64 - fails
  5. win8x64 - works

The specific methods that fail are:

  • SDL_RenderSetViewport()
  • SDL_RenderSetClipRect()
  • setting RenderContext.color (which uses SDL_SetRenderDrawColor)

I'm creating the Window as a OPENGL, but not using any of my own OpenGL. On the machines that fail with these methods, they also fail/do nothing if I use any pyopengl function within the SDL application. However, those same machine correctly run pyopengl functions under a GLUT window.

SDL_SetRenderTarget() does work on all machines though.


Sorry if this is my fault (or sdl2's fault rather than pysdl2's), but I can't guess what is wrong here...

Comments (14)

  1. Marcus von Appen repo owner

    Could you please provide a minimal example (both, pyopengl and pysdl) to recreate your issues?

    Below is a small set of checks to ensure that the issue is really related to the SDL methods in some way:

    • make sure that your flags were actually applied to the window ( check SDL_GetWindowFlags()).
    • make sure that the correct driver is used by SDL2 (probably enforce it by setting the SDL_VIDEODRIVER environment variable)
    • ensure that the OpenGL drivers actually work (esp. on the Win7 platform)
    • ensure that you do not mix up the contexts - I remember that some later PyOpenGL version became GL_Context-aware. Check, if it can use the GL context of SDL (or the other way around).
  2. Bil Bas reporter

    One thing I wasn't doing was creating an SDL_GL_Context. Since the code (both SDL Render functions calling opengl or using pyopengl directly) worked on some of the machines, I assumed this wasn't an issue - perhaps my machine somehow doesn't need an explicit context creatin?

    I don't have access to any of the test machines where this failed for a few days, so I can't check this issue and the ones you suggested.

    If this is indeed the problem, perhaps sdl2.ext.Window should manage an SDL_GL_Context for you if it is created in OPENGL mode?

  3. Marcus von Appen repo owner

    As far as I know, the contexts in do not need to be explicitly created for the OpenGL window.

    From your list, only Win7 (64-bit) seems to have issues. I can only guess, what's wrong with them, but I'd check, if they can deal with OpenGL properly and if their drivers are up to date.

  4. Bil Bas reporter

    At least one of those machines were updated to the very latest drivers and it is fine with GLUT-based Opengl and commercial OpenGL-based games. Thanks for the ideas though - I'll keep plugging at it.

  5. Bil Bas reporter

    I've had the opportunity to test again on one of the failing machines and, well, I got another bizarre result! With a SDL_GL_CreateContext, GL commands still don't do anything but SDL_RenderSetViewport, which did nothing before, now does have an effect, but inverts y on their machine!

  6. Bil Bas reporter

    On the test machine, SDL_RenderSetClipRect seems to be in the correct position, but is about half as wide as it should be!

    SDL_RenderSetClipRect & SDL_RenderSetViewport work perfectly on my machine, as do pyopengl functions (regardless of whether or not I'm explicitly creating an OpenGL context).

  7. Bil Bas reporter

    Was finally able to get direct access to a machine this problem occurred on, so I could try more things to see what exactly was going wrong. As far as I can tell, it is all about contexts.

    On my machine, when I create an regular SDL render context, it is also a valid GL context, so I don't need to manually create a GL context via SDL_GL_CreateContext() and I can use both SDL and pyopengl commands to affect it (and those SDL functions that are hard-coded to only work on OpenGL, such as SDL_RenderSetClipRect which always uses glScissor() and can't possibly work with any other render driver!). Even when I run in a win7 VM, it is, I assume, still using OpenGL.

    On most other machines, the SDL render context doesn't count as a GL context, so GL commands fail (but since I'm using SDL_Textures with it, it must be a hardware accelerated context, even if it isn't a context that is visible to pyopenGL commands - presumably a DirectX context?) . On these machines, if I create a SDL_GL context, which is obviously guaranteed to be a GL context, then it is separate from the SDL render context (both exist and can be used with SDL and GL commands, but they are entirely separate).

    So, doesn't seem to be anything directly related to pysdl2, but rather poor behaviour/documentation of sdl2 itself; sorry!

    (EDIT: Well, this relies on the fact that SDL2 is ignoring the SDL_WINDOW_OPENGL I send when I create the window, which seems the only explanation).

  8. Marcus von Appen repo owner

    It probably relates to the SDL2 documentation being not explicit enough about the driver behaviour. Thus I wrote

    """ make sure that the correct driver is used by SDL2 (probably enforce it by setting the SDL_VIDEODRIVER environment variable) """

    The SDL2 API also features a render driver hint (see and also allows you to choose explicitly what kind of rendering driver to use via SDL_CreateRenderer().

    If you are setting one of those explicitly in your application, does it work on every machine?

  9. Bil Bas reporter

    I started using SDL_SetHint(SDL_HINT_RENDER_DRIVER, b"opengl") and that seemed to help encourage the renderer to actually use OpenGL. I presume that the SDL_WINDOW_OPENGL just asks that the window support OpenGL, not that it actually enforce the USE of opengl, which seems really very odd...

    Thanks for the thoughts you shared in this thread. I was really scratching my head over this!

  10. Marcus von Appen repo owner

    Good to hear that everything works for you now. I'll close the issue. If there are any more problems with the OpenGL behaviour, please reopen it or create a new issue.

  11. Log in to comment