OpenGL plug-in causing white regions in host app

Hi,

I am working on an audio plug-in, with display code written using OpenGL. It exists as an OSX component, and a Windows dll.

The plug-in can be loaded into several host audio applications (Logic, Garage Band, Bias Peak, Cubase, Ableton Live, etc) - with most of the these hosts, everything functions correctly.

In one specific host, I find that when I open up my plug-in’s GUI, it causes solid white rectangles to appear on the host’s GUI, which eventually cause the entire host’s GUI to be solid white. My plug-in continues to render correctly in the foreground.

If I then close my plug-in’s GUI, the host app remains solid white. The host app has a “F11 for fullscreen” feature, and if I press F11, the host goes to fullscreen and starts displaying correctly again.
Please, could anyone suggest what sort of things might cause this problem, or what I might be able to do to investigate it further, or try to fix it?

Thanks for any help.

Paul

Detail on the host aplication are needed, especially to compared against others. Maybe they also use the 3D hardware acceleration, in a conflicting way ?

Does this always happens, whatever the hardware setup ?
Depending on :

  • operating system version
  • video hardware
  • video drivers version
    there can be differences.

On your plugin, how do you create the OpenGL context ?

Thanks for the response.

Hosts that the plug-in works fine with include Cubase (Win & OSX), Logic (OSX), Digital Performer (OSX), Pro Tools (OSX), Garage Band (OSX), Wavelab (Win).

The problem occurs in Ableton Live 8 (OSX or Win). The problem does not occur in previous versions of Ableton Live. (I have contacted Ableton about this issue but have not yet heard back from them).

The plug-in generally functions correctly in OSX 10.4, 10.5 and 10.6, and Windows XP, Vista and 7. The problem with Ableton Live 8 seems to occur in any of these OS’s, so I think its independent of operating systems, video hardware and video drivers.

On Windows I create the OGL context with ChoosePixelFormatEx, SetPixelFormat and wglCreateContext, and then every frame before I start the display code I call wglMakeCurrent.

In OSX I call aglChoosePixelFormat, aglCreateContext and aglSetDrawable to create and then aglSetCurrentContext every frame.

Thanks again for helping

From this stack trace http://forum.ableton.com/viewtopic.php?f=2&t=137582 apparently Ableton Live 8 also uses OpenGL for its own rendering.

So your plugin must play nice by saving the current context (if there is one), doing its own rendering, then restore context before giving back control to main host app.

(or use the rendering context of the host if present, but that may be a bad idea)

I’ve done a bit more experimentation, incrementally removing stuff from my code, and I’ve isolated the conflict down to a single line of code in my plug-in.

I have some parts of my interface rendered with glDrawPixels, and some parts rendered using proper textures. If I remove all the texture code, and just use the draw pixels, it works fine. If I then add in the single line

glGenTextures(1, &texRet);

in my code, it starts causing the white rectangles in the host GUI.

My assumption is that perhaps Ableton Live 8 is using texture names that it hasn’t claimed for itself using glGenTextures, or something (sorry, I’m an OGL beginner so I don’t know the right terms for this).

As an experiment, I tried forcing my texture names to start from 1000, and using glIsTexture to check that they are valid names, and that seems to stop the problem (so I guess that’s a work around that I could use).

A different issue which I then immediately saw, although I don’t know if this is connected with the first problem, is that now, using the method of starting my texture names from 1000, I don’t get white rectangles in the host, but the first time I open my plug-in, all the textures are just sold blocks of colour. If I then open up a second instance of the plug-in within the host, the textures display correctly. Also, with just one instance of the plug-in, if I switch to a different view, and then switch back to the first view, it makes the textures display correctly.

Running Ableton (both alone then with your plugin) with glIntercept will probably help you guess how to behave well with it.

Try using glIsTexture() to check if the name returned from glGenTextures() is in use.

Regards,
Patrick

I have tried using glIsTexture to check the names I was getting back from glGenTextures. It didn’t seem as if any were already textures. Strangely, just calling glIsTexture on them then seemed to change the behaviour in that it got rid of the white rectangles on the host GUI while the plug-in was present, but then when I closed the plug-in, the white rectangles started appearing - I don’t know what this means.

I am new to OGL, but I understood that glGenTextures was meant to return an array of names which weren’t textures. I guess what I’m seeing could be an OpenGL driver problem (?).

Anyway, forcing my texture names to start at a higher arbitrary number seems to have worked around the issue, so I think I’ll follow that as a way forward.

Thanks for everyone’s help.

Just in case anyone ever google’s this thread and is interested in the final answer…

After further experimentation I found that my problem was coming from not setting my OGL context to be the current one before allocating the texture names.

This meant that I had a race condition between my plug-in and the host application, both of which are using OGL for rendering, and so the current OGL context was getting switched backwards and forwards.

I was experiencing a similar problem developing an OpenGL Audio Unit inside Ableton Live - this thread helped me a lot to solve my problem.

In my case, I was already making the context current before generating textures, but was getting the white regions on closing the plugin window. I solved it by ensuring that the context was also current before deleting any textures. Then the white regions stop occurring.