OpenGL Error 1281 - "Invalid Value"

[Malte Nuhn]

In some constellations (seems to somehow depend on the zoom level and the window size), I am able to produce very "nasty" OpenGL renderings. When seeing these strange images, I get a lot of OpenGL error messages (I just improved the error message for that to give more detail).

It is OpenGL Error "1281", which translates to "Invalid Value".

I currently can't provide more information about this. However, I had these problems already every now and then, so I guess it is not related to some recent changes.

[Malte Nuhn (malte.nuhn)]

I tried to debug the application with "gDEBugger - an OpenGL Debugger and Profiler". Unfortunately it can't debug JAVA applications on a Mac (but on Windows and Linux). So it might be interesting if someone else can reproduce this bug on his non-Mac machine.

Here are the details of my machine:

////////////////////////////////////////////////////////////
// This File contain a system information snapshot
// Generation date: Saturday, October 9, 2010
// Generation time: 00:33:38
//
// Generated by gDEBugger - an OpenGL Debugger and Profiler
// www.gremedy.com
////////////////////////////////////////////////////////////

////////////////////////////////////////////////////////////
// System
////////////////////////////////////////////////////////////
Item Value
Computer Name codebook.local
User mnuhn
Operating System Version (name) Mac OS X
 10.5.8
 - Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386
Operating System Version (number) 9.8.0
Number Of Processors 2
System Type I386
Total Physical Memory 2048 MB
Available Physical Memory 4096 MB
Total Virtual Memory 0 MB
Available Virtual Memory 380 MB
Total Page Files 1024 MB
Available Page Files 145 MB
Network Card Id (MAC address) FF-FF-FF-FF-FF-FF
Computer Path /usr/bin
                              /bin
                              /usr/sbin
                              /sbin

////////////////////////////////////////////////////////////
// Display
////////////////////////////////////////////////////////////
Item Value
Number of Monitors 1
Primary Monitor Name Manufacturer: 00004C2D Model: 000004D4 Serial Number: XXXXXXXX Manufacture Date: XXXXXXXX
Screen Resolution 1920 by 1080 pixels

////////////////////////////////////////////////////////////
// Graphic Card
////////////////////////////////////////////////////////////
Item Value
Renderer Vendor Intel Inc.
Renderer Name Intel GMA X3100 OpenGL Engine
Renderer Version 1.2 APPLE-1.5.48
Shading Language Version 1.20
Renderer Type Hardware renderer

////////////////////////////////////////////////////////////
// OpenGL Extensions
////////////////////////////////////////////////////////////
no. Extension name
1 GL_APPLE_aux_depth_stencil
2 GL_APPLE_client_storage
3 GL_APPLE_element_array
4 GL_APPLE_fence
5 GL_APPLE_flush_buffer_range
6 GL_APPLE_flush_render
7 GL_APPLE_object_purgeable
8 GL_APPLE_...

[Markus Langenberg (markus-langenberg)]

I know the cause for this problem, but I have no idea what might trigger it. The problem is the following: Currently, JHV only uses textures whose sides have a length which is a power of two. Obviously, in most cases, for the selected region, this constraint does not hold. So the selected region is loaded into a bigger texture, leaving the unused parts of the texture untouched. Thus, these unused parts contain invalid data (as in the lowest quarter of your screenshot) or leftovers from previous images (as in the the third quarter of your screenshot). Usually, these areas are not visible, because the size of the valid texture is given to the shader so that it can scale the texture coordinates according to this. However, this failed in your case.

I was not able to reproduce the error. To get a better idea about what happened, here are some questions:

- Is the bug reproducible?
- When it appears, do the broken areas always appear at the bottom of the screen? Or do the invalid areas also appear at the right side of the screen (which is not the case on your screenshot) ?
- If you zoom out and in to the same zoomlevel again, does it appear again?
- When you keep the zoomlevel but pan around, does it stay the same?
- When playing a movie, does it stay the same?

If you answer the last three questions with "yes", this is clearly a numerical problem, otherwise this might get even more ugly.

The error code "Invalid value" refers to an OpenGL command which was called with values out of range. Unfortunately, this is not very helpful because I don't know, which command caused it. The scaling seems to be broken, but the shader is still intact up and running (the color table still works, for example, assuming you have not changed the order of the filters). My first idea would be, that the command to set the scaling factor causes the error, but according to the OpenGL Reference, this command is not able to throw an "Invalid value". So I am in the dark about this...

We have to opportunities here:
1) I can reformulate the scaling, to that it is performed inside the Java virtual machine rather than the shader program on the graphics card. In the past, this was not possible, but I changed some things in the meantime, so I can do so. Maybe this can help to either avoid the error or locate it better.
2) You (or anyone else able to reproduce this bug) can insert some debugging code - Namely to insert some calls to glGetError(). OpenGL only has one error flag, always containing the last error since glGetError() was called. Right know, glGetError() is called after every frame. Thus, it only indicates that an error appeared during this cycle, but not where. Inserting more calls to glGetError() gives information about the part of the code, where the error appeared, in the best case the single line that causes it. Knowing this line and the values it is called with would clearly be enough to solve this problem.

[Malte Nuhn (malte.nuhn)]

Just as a remark: I do not know if this information is important, but as you can see in one of my above posts, my graphics card is also capable of dealing with non_power_of_two textures...

Now to your questions:

- Is the bug reproducible?

Yes! On Mac start JHV. I figured out that the MainImagePanel's size is 1363 x 796 on startup (debug print in componentResized(..)).

Now some new info: I only have problems with AIA data, so load e.g. "SDO_AIA_AIA_171_F2010-08-01T00.00.00Z_T2010-08-02T00.00.00ZB216.jpx" that Daniel sent around at ESTEC.

Then I press three times on the zoom button and then the strange behavior happens. In this case I do not get a "stripe of invalid data" - instead the area I'm looking at slightly changes (slight zoom, slight shift). After that no new image data is displayed, even though a movie is playing (and the frame number increases).

- When it appears, do the broken areas always appear at the bottom of the screen? Or do the invalid areas also appear at the right side of the screen (which is not the case on your screenshot) ?

I can't find too many constellations in which this happens. I somehow get the impression that it is always broken on the BOTTOM of the image. Another thing is that the image data in the "correct area" above of this is sometimes streched, too.

- If you zoom out and in to the same zoomlevel again, does it appear again?

Yes!

- When you keep the zoomlevel but pan around, does it stay the same?

In this (reproducible) case described above, panning only introduces a black border on the side where new image data should appear. After some while (some 100ms) the old (frozen) image is restored, so that after all no panning has taken place.

- When playing a movie, does it stay the same?

I'm not quite sure what your question is, but: I do not need to have the AIA movie in playing state. However, even if I press "play" in this buggy state, the image data seen on my display does not change (the picture is "frozen").

If I got you correct, this means that we have a numerical problem. If you want I can add the glGetError() statements to a special debugging branch. Please let me (once again) know if you still need this information.

[Markus Langenberg (markus-langenberg)]

After some more hints, Malte just found out the reason for this bug: His graphics card only supports textures up to 2048x2048, whereas is screen is so big, that the decoder provides an image greater than that. The solution to this problem is tiling the image in OpenGL mode if this is the case. I will fix this, soon.

[Malte Nuhn (malte.nuhn)]

I'm afraid the Bug is not yet fixed...

Now the event overlays are "messed up", see the attached screenshot.
It seems like something with reading/displaying images has been broken.

If you want to reproduce the problem, note that you cannot just start the JAR generated from the latest trunk, since it does not include the HEK support. Just open the trunk in Eclipse and run

HEKPlugin/Default Package/JavaHelioViewerWithHEK.java

Please let me know what I can do to support you with this problem.

[Daniel Mueller (dmueller-esa)]

Hi Malte & Markus,

>If you want to reproduce the problem, note that you cannot just start the JAR generated from the latest trunk, since it does not include >the HEK support. Just open the trunk in Eclipse and run
>HEKPlugin/Default Package/JavaHelioViewerWithHEK.java

I could not find that particular file, but could launch src/HEKPlugin/src/HEKPlugin.java .

Unfortunately, I can reproduce the display problems of the event markers with OpenGL 2.1 under OS X (see screenshot - the event markers appear as very thin horizontal line segments). Markus, can you help?

Thanks,
Daniel

[Markus Langenberg (markus-langenberg)]

Fix commited - I modified the generation of OpenGL textures from ImageData-Objects, which interfered with the generation of OpenGL textures from Java BufferedImages. I only had to insert a few lines to set some values back to the default value.