Issue Details (XML | Word | Printable)

Key: JOGL-359
Type: Bug Bug
Status: Reopened Reopened
Priority: Major Major
Assignee: jogl-issues
Reporter: djclayworth
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Problem when hardware rendering fails

Created: 09/Jul/08 01:16 PM   Updated: 03/Mar/09 12:12 PM
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Time Tracking:
Not Specified


Operating System: All
Platform: All

Issuezilla Id: 359
Participants: djclayworth, jogl-issues and kbr

 Description  « Hide

I have an application where I am drawing a number of GLJPanels in a component
(more than fifty). After drawing a few I get a GLException with the message:

pbuffer creation error: wglCreatePbufferARB() failed: tried 9 pixel formats,
last error was: (Unknown error code 0)

This is probably due to running out of resources (video memory?) and what I
expect. However what happens after that is unexpected. I start to get NPEs
whenever I draw any GLJPanel.

The GLException is thrown in GLDrawableFactory.createGLPbuffer() and caught in
GLJPanel.initialize(). GLJPanel.initialize() sets the flag
'hardwareAccelerationDisabled' true (meaning that software rendering will be
used from now on) and initializes the variables 'offscreenDrawable' and
'offscreenContext', which are needed for software rendering.

The trouble is that 'hardwareAccelerationDisabled' is static while
'offscreenDrawable' and 'offscreenContext' are not. This means that other
instances of GLJPanel are forced to do software rendering but without the
variables being initialised. This results in null pointers.

I am running on Windows XP with a Radeon X550 card. I'm using JOGL 1.1.1 with
JRE 5.0.

kbr added a comment - 11/Jul/08 06:11 PM

I'm sorry, but the GLJPanel isn't intended to be used in this extreme fashion. I think you are going to
need to manually manage your off-screen rendering. Because you have the GLJPanel source code
available, you could create your own JPanel subclass which does similar operations to the GLJPanel to
interoperate with Java 2D, but which uses a common off-screen pbuffer for all of the components'
rendering, or something similar.

A restructuring of the GLJPanel's code is in progress which might make it easier to install better error
checking, but this would need to be left in the hands of the community as our development priorities
are elsewhere. Please watch the JOGL forum for updates.

Because this is an extreme use case, closing this bug as "won't fix".

djclayworth added a comment - 03/Mar/09 12:12 PM

While I understand that this is an extreme case, I'm not asking that fifty
simultaneous GLJPanels are supported. In fact you don't need that many GLJPanels
to reproduce this; two GLJPanels is sufficient as long as
hardwareAccelerationDisabled is set true.

What I am asking is that when GLJPanel switches to hardwareAccelerationDisabled
it does so in a way that doesn't leave null pointers hanging - or alternatively
that the null pointers are checked for by each instance of GLJPanel when they
find hardwareAccelerationDisabled true.

TO REPRODUCE: Create two GLJPanels; perform some operation on one that causes
hardwareAccelerationDisabled to be set true internally; draw both GLJPanels.

EXPECTED: Both GLJPanels are drawn, either with or without hardware acceleration.

ACTUAL: Null pointer thrown.