Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.Windows.Forms control fails to create context if framebuffer properties are changed #119

Open
katz1 opened this issue Oct 16, 2018 · 2 comments

Comments

@katz1
Copy link

katz1 commented Oct 16, 2018

Hi!

I am trying to set up an OpenGL.GlControl in a WPF window using OpenGL.NET 0.7.1 from NuGet. I am experiencing issues if I change some of the Framebuffer properties of the control.

The following example works without issues:

<WindowsFormsHost Grid.Column="0" Margin="20">
    <opengl:GlControl ContextCreated="GlControl_ContextCreated" Render="GlControl_Render" />
</WindowsFormsHost>
private void GlControl_ContextCreated(object sender, OpenGL.GlControlEventArgs e)
{
    Gl.MatrixMode(MatrixMode.Projection);
    Gl.LoadIdentity();
    Gl.Ortho(0.0, 1.0f, 0.0, 1.0, 0.0, 1.0);
    Gl.MatrixMode(MatrixMode.Modelview);
    Gl.LoadIdentity();
}

private void GlControl_Render(object sender, OpenGL.GlControlEventArgs e)
{
    var senderControl = sender as GlControl;	
    Gl.Viewport(0, 0, senderControl.ClientSize.Width, senderControl.ClientSize.Height);
    Gl.Clear(ClearBufferMask.ColorBufferBit);
	
    Gl.Begin(PrimitiveType.Triangles);
    Gl.Color3(1.0f, 0.0f, 0.0f); Gl.Vertex2(0.0f, 0.0f);
    Gl.Color3(0.0f, 1.0f, 0.0f); Gl.Vertex2(0.5f, 1.0f);
    Gl.Color3(0.0f, 0.0f, 1.0f); Gl.Vertex2(1.0f, 0.0f);
    Gl.End();
	
    Debug.Assert(Gl.GetError() == Gl.NO_ERROR);
    Gl.ActiveTexture(TextureUnit.Texture0);
    Debug.Assert(Gl.GetError() == Gl.NO_ERROR);
}

Now if all I do is change the control to have a depth buffer like this:

<WindowsFormsHost Grid.Column="0" Margin="20">
	<opengl:GlControl ContextCreated="GlControl_ContextCreated" Render="GlControl_Render" DepthBits="8" />
</WindowsFormsHost>

I will receive a System.NullReferenceException at the Gl.ActiveTexture call. Same happens if I change the ColorBits to 24 for example, the ActiveTexture function will not be loaded, so I am guessing there are issues with setting up the context.

@luca-piccioni
Copy link
Owner

I'm not aware of how WPF will initialize the designer properties. These are the default values: ColorBits is 24 (reference), while all others have defaulted to 0 (DepthBits, StencilBits and MultisampleBits).

Sincerely I doubt you don't have a ColorBits=24 + DepthBits=8 framebuffer configuration (it's quite a basic setup), indeed there's something wrong here.

Anyway, if the GL context creation fails, an exception shall be thrown, and it should be intercepted by your development environment. Or WPF masks every exception?

Moreover, the GlControl, when in DesignMode, should preview which framebuffer configuration would select with the current Framebuffer designer properties, and if it fails, it should show the exception about.

@katz1
Copy link
Author

katz1 commented Oct 17, 2018

Thanks for the response.
Unfortunately I do not receive any exception until the ActiveTexture call. WPF should not mask exceptions normally, but the WindowsFormsHost control may have some strange behaviour.
I find it especially strange that many other functions like GenTexture, BindTexture or TexImage2D are loaded, only the ActiveTexture function is missing (or throwing a Nullptr exception to be more specific).

I meant to use a 32 bit depth buffer earlier, but that does not make a difference.
I also started testing inside the HelloTriangle.WPF sample to avoid side effects which could be present in my solution, but this wasn't the cause.

Do my framebuffer settings have to match an element in the DeviceContext.PixelsFormats array? I have 75 items there but there is none with 24 bit color 32 bit depth and 0 bit stencil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants