Bug 638 - Problem requesting non-hardware-accelerated capabilities on a device capable of hardware acceleration
Summary: Problem requesting non-hardware-accelerated capabilities on a device capable ...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: windows (show other bugs)
Version: 2
Hardware: All windows
: --- normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2012-11-09 11:54 CET by Jonas Thedering
Modified: 2012-11-11 09:18 CET (History)
0 users

See Also:
Type: ---
SCM Refs:
jogl f67d310743cd6dee3d3005b96b61e9adae628899
Workaround: ---


Attachments
Patch for WindowsWGLGraphicsConfigurationFactory.java (1.01 KB, patch)
2012-11-09 11:54 CET, Jonas Thedering
Details | Diff
GIT patch (1.53 KB, patch)
2012-11-09 17:56 CET, Jonas Thedering
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Thedering 2012-11-09 11:54:43 CET
Created attachment 381 [details]
Patch for WindowsWGLGraphicsConfigurationFactory.java

I'm creating a GLCanvas with a GLCapabilities object that requests non-hardware-accelerated capabilities and a custom chooser like in this code snippet:

GLCapabilities caps = new GLCapabilities(null);
caps.setHardwareAccelerated(false);
GLCanvas canvas = new GLCanvas(caps, new CustomCapabilitiesChooser(), null, null);

The problem is that the provided chooser's chooseCapabilities method is only supplied GLCapabilities that are hardware accelerated.

After further investigation I could find the reason for this in the class WindowsWGLGraphicsConfigurationFactory. The method updateGraphicsConfiguration tries to use updateGraphicsConfigurationARB (which only provides hardware-accelerated capabilities) and only if that method fails, it uses updateGraphicsConfigurationGDI (which also provides non-hardware-accelerated capabilities):

if( !updateGraphicsConfigurationARB((WindowsWGLDrawableFactory)factory, config, chooser, hdc, extHDC, pfdIDs) ) {
	updateGraphicsConfigurationGDI(config, chooser, hdc, extHDC, pfdIDs);
}

I have implemented a simple solution by checking if non-hardware-accelerated capabilities are requested and skipping the ...ARB method in that case, which is attached as a patch. A better solution might be to supply both the capabilities from ARB and GDI to the chooser.
Comment 1 Sven Gothel 2012-11-09 17:00:57 CET
Sounds great. Can you send me a git patch or pull request so we can preserve your authorship ?

I guess the non hw-accel use case is sort of limited and we can live w/ this solution,
i.e. skipping the ARB caps if software rendering is requested.
Comment 2 Jonas Thedering 2012-11-09 17:56:57 CET
Created attachment 382 [details]
GIT patch

This is the patch in a format that can be applied using git apply
Comment 3 Sven Gothel 2012-11-11 09:18:57 CET
jogl commit f67d310743cd6dee3d3005b96b61e9adae628899

Thx.