anathema's picture

Getting GraphicsModeException from WinGraphicsMode constructor

Project:The Open Toolkit library
Version:1.1-2014-01-02
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
Description

I get this :-)

System.TypeInitializationException: The type initializer for 'Digitalis.LDTools.Controls.OpenGL.ModelView' threw an exception. ---> System.TypeInitializationException: The type initializer for 'OpenTK.Graphics.GraphicsMode' threw an exception. ---> OpenTK.Graphics.GraphicsModeException: No GraphicsMode available. This should never happen, please report a bug at http://www.opentk.com
at OpenTK.Platform.Windows.WinGraphicsMode..ctor()
at OpenTK.Platform.Windows.WinFactory.CreateGraphicsMode()
at OpenTK.Graphics.GraphicsMode..cctor()
--- End of inner exception stack trace ---
at OpenTK.Graphics.GraphicsMode.get_Default()
at Digitalis.LDTools.Controls.OpenGL.ModelView..cctor() in D:\Development\Digitalis.LDTools\ModelView.cs:line 210

I am running the code on WindowsXP on a VirtualBox VM, which might have something to do with it; however, this has worked in the past and the only thing I have changed is the build of OpenTK that I'm compiling against. At present I'm using the trunk, rev 3056, built locally.

The same code works normally on various Windows7 machines and on a real XP machine.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Status:open» confirmed

The latest revisions ignore software accelerated contexts - we should probably add a fallback if no hardware accelerated contexts are available.

In this specific case, you can enable 3d hardware acceleration in your VM settings (don't forget to install the guest additions either).

c2woody's picture

#2

One thing I'd like to this again is from
http://www.opentk.com/node/1954

GetModesPFD requests OpenGL-support and window accessibility but also allows for generic pixel formats, whereas GetModesARB does not include the OpenGL and draw-to-window flags (which I think it really should as posted in the referenced thread) but forces non-generic pixel formats only.

Both functions should request the same/comparable flags if possible, but I'm not sure how the generic format fallback would fit in there (only using the fallback if no fully-accelerated modes were found may not be enough??).

the Fiddler's picture

#3

The ARB path is taken only if a recent, hardware accelerated driver exists (otherwise ARB_wgl_pixel_format won't be available and we'll fall back to the PFD codepath). IIRC, the OpenGL and draw-to-window flags are the defaults (should probably double-check and document this).

Once we fall back to the PFD codepath, it makes sense to request both accelerated and generic formats: select the closest accelerated match, if one exists, or fall back to software acceleration otherwise. Right now, we are missing the fallback - hence the exception.

c2woody's picture

#4

Quote:

the OpenGL and draw-to-window flags are the defaults

Can't find that anywhere, the very most implementations out there specify both flags unconditionally.
Would there be a case when GetModesARB is called (or its returned modes are used) for offscreen/pbuffer or dummy rendering?

Btw. the first call to Wgl.Arb.ChoosePixelFormat has no check for the return code (could happen that num_formats is not changed then, which is undefined).

anathema's picture

#5

Ah, thanks :-) Yes, that was the cause. I've added handling for that exception to my code now, since it's a reasonable bet it'll show up on someone's machine sooner or later...

c2woody's picture

#6

Quote:

the OpenGL and draw-to-window flags are the defaults

This is definitely false as seen with the ATI drivers where 32+8bpp was requested which could not be fulfilled by and draw-to-window mode and thus a pbuffer-style format was returned.

the Fiddler's picture

#7

Status:confirmed» in progress

Fixed the flags, working on non-accelerated fallback.

c2woody's picture

#8

The fallback would be related to GetModesPFD, right? So if it returns no modes, GetModesPFD could be called again and return all modes where GENERIC_FORMAT as well as PFD_GENERIC_ACCELERATED (accelerated generic format) and if that returns no modes either, be called again returning any mode (unaccelerated generic formats).

jdomnitz's picture

#9

That sounds right to me... looking forward to seeing that fallback working again

c2woody's picture

#10

There never was a fallback for generic-type formats, there was a change to disallow generic formats and a fallback may be added if there aren't any non-generic formats.

If you can compile current svn sources (and possibly can trace the OpenTK sources) I may put up a patch if there's interest.