Is there a stacktrace available?

I have one.

Revision 1048.
Running Tests->RenderStates.
http://agatelib.pastebin.com/m24dfe198

openSUSE 11.1 + Mono:
Mono JIT compiler version 2.4.2.3 (tarball Mon Jul 27 17:01:11 UTC 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none

Thank you.

According to the glXMakeCurrent documentation, this method should not cause a BadValue error.

Can you please say which video card / drivers you are using? I *think* I have seen encountered something similar on nvidia drivers before, which might mean there's something wrong with context creation.

Geforce 8600 GT with 185.18.14 drivers.
The particle branch on which Im working works fine btw..

So I've tested this a little more.. in Debian with an Intel X3100 graphics card, everything works, although (amusingly) I see these two lines which are probably just due to the driver not reporting vsync properly:

In VirtualBox on Windows Vista with OpenSuSE or Ubuntu guest I get the message:
OpenGL Error: Assertion failed: src, file /mnt/tinderbox/add-2.2/src/VBox/GuestHost/OpenGL/util/mem.c, line 118

Full output available here: http://agatelib.pastebin.com/f57bffbb0

One of the differences between the old version which is in the particle branch is that is uses OpenTK 0.9.6, and the new stuff uses OpenTK 0.9.8. I will try to upgrade to OpenTK 0.9.9 and see if that improves things. At first I was thinking it was due to the request to create an OpenGL 3.1 context (and maybe it is with the nVidia driver) but that doesn't seem to be the case with the Virtual Box driver. At least, changing the requested version to 1.0 doesn't fix it.

IIRC, one of the differences between 0.9.6 and 0.9.8 is that the latter prefers glXChooseFBConfig over glXChooseVisual, if both are available and you ask for a 3.0+ context. This adds support for FSAA and OpenGL 3.0, but it seems to cause problems in some drivers.

The failed assertion looks like a Chromium bug (Chromium is the transport layer / driver for VirtualBox 3d acceleration). What happens if you disable hardware acceleration in your VM settings?

The BAD_CONTEXT issue implies that VSync is set without a current context. The driver exposes glXSwapIntervalSGI (otherwise we'd get "Context supports vsync: False"), the context has been created (otherwise the code wouldn't even get to this point) but the actual call fails because no context is current at that point. OpenTK.Graphics.GraphicsContext should probably check for this error condition (I'll add this to my todo list).

Yeah, on the failed assertion if I disable hardware acceleration then it works. I checked the BAD_CONTEXT issue too, above where it says "Context supports vsync" it gives a line that says "Making context 157296496 current..." I added an explicit MakeCurrent call right after the context is created, and now I see this output:

If I toggle VSync on an off as the application is running, I see this output:

This is testing in virtual box with 3D acceleration disabled. The output indicates that the context supports vsync.

I downgraded to OpenTK 0.9.6 for now. Agon, does that resolve the issue?

Yeah, SpriteTester or RenderStates works, now.

Ok, I'm marking this issue as fixed.
I still would like to upgrade to the most recent OpenTK, but it looks like I will have to do that in a branch to make sure it doesn't disrupt the trunk development. So this means you can merge the particles branch into the trunk?

Uhm probably if I find time and motivation to do it.

Ok, let me know if there's any other problem. I could do the merge if you don't have time, just let me know whatever's best for you.

Automatically closed -- issue fixed for 2 weeks with no activity.