Bug 359 - Problem when hardware rendering fails
Summary: Problem when hardware rendering fails
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All all
: P3 normal
Assignee: Sven Gothel
Depends on:
Reported: 2008-07-09 01:16 CEST by Sven Gothel
Modified: 2010-11-19 13:05 CET (History)
0 users

See Also:
SCM Refs:
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:51:31 CET

---- Reported by djclayworth 2008-07-09 13:16:32 ----

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.

---- Additional Comments From kbr 2008-07-11 18:11:29 ----

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".

---- Additional Comments From djclayworth 2009-03-03 12:12:40 ----

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.

--- Bug imported by sgothel@jausoft.com 2010-03-24 07:51 EDT  ---

This bug was previously known as _bug_ 359 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=359
Comment 1 Sven Gothel 2010-11-19 13:05:03 CET
state of GLJPanel is 'hardly supported'