Bug 838

Summary:	glReadPixels is receiving data in the wrong order with certain display drivers
Product:	[JogAmp] Jogl	Reporter:	Dennis Cosgrove <dennisc>
Component:	awt	Assignee:	Sven Gothel <sgothel>
Status:	RESOLVED WORKSFORME
Severity:	major	CC:	gouessej
Priority:	---
Version:	2
Hardware:	pc_all
OS:	windows
Type:	---	SCM Refs:
Workaround:	---

Description Dennis Cosgrove 2013-09-19 20:32:11 CEST

We have received multiple reports of strangely colored graphics output from the field.

We have a machine on which we can reproduce the problem in the lab.  Windows 7, 64 bit, Intel(R) HD Graphics driver.

It appears that the color component order for glReadPixels is not receiving what it expects.  The alpha channel certainly seems to be red by this observed incorrect rendering:

  black -> red
  red   -> red
  green -> yellow
  blue  -> magenta

To eliminate our system from the problem, the Gears demo runs perfectly fine when using a GLCanvas, but exhibits the color component order problem when switched to use a GLJPanel.

Certainly the Intel driver has earned its place on the usual suspects list.  This suspicion is strengthened by the fact that glGetting GL_IMPLEMENTATION_COLOR_READ_FORMAT and GL_IMPLEMENTATION_COLOR_READ_TYPE both result in glErrors.

However, the colors are correctly rendered on the exact same machine when using jogl 1.1.1a.  I was hopeful when I discovered that jogl 1 uses GL_UNSIGNED_INT_8_8_8_8_REV (as opposed to GL_UNSIGNED_BYTE in jogl 2).  Sadly, using GL_UNSIGNED_INT_8_8_8_8_REV in jogl 2 did not solve the problem.  Still, the fact that jogl1 can correctly handle this problem gives me hope.

Comment 1 Sven Gothel 2013-09-21 05:28:04 CEST

Is this reproducible w/ one of our unit tests, i.e. TestGearsES2GLJPanelAWT,
which performs a 'snapshot' via ReadPixels (but w/ 3 components only, you may tweak it) ?

If not, please provide a unit test and probably a trace log of the same,
best w/ latest aggregated build available (-> wiki).

The fallback values:
  3 components:
                dFormat = GL.GL_RGB;
                dType   = GL.GL_UNSIGNED_BYTE;            

  4 components:
                dFormat = GL.GL_RGBA;
                dType   = GL.GL_UNSIGNED_BYTE;            

should work for all platforms and all GL profiles ofc.

Comment 2 Sven Gothel 2013-09-21 05:42:53 CEST

(In reply to comment #1)
> Is this reproducible w/ one of our unit tests, i.e. TestGearsES2GLJPanelAWT,
> which performs a 'snapshot' via ReadPixels (but w/ 3 components only, you
> may tweak it) ?
> 
> If not, please provide a unit test and probably a trace log of the same,
> best w/ latest aggregated build available (-> wiki).
> 
> The fallback values:
>   3 components:
>                 dFormat = GL.GL_RGB;
>                 dType   = GL.GL_UNSIGNED_BYTE;            
> 
>   4 components:
>                 dFormat = GL.GL_RGBA;
>                 dType   = GL.GL_UNSIGNED_BYTE;            
> 
> should work for all platforms and all GL profiles ofc.

Note: The fallback has been introduced
w/ commit b33bdf41cf53f37203643a8551bf5d94b42a8fab

http://jogamp.org/git/?p=jogl.git;a=commit;h=b33bdf41cf53f37203643a8551bf5d94b42a8fab

Comment 3 Julien Gouesse 2013-10-01 10:37:41 CEST

(In reply to comment #0)
> We have received multiple reports of strangely colored graphics output from
> the field.
> 
> We have a machine on which we can reproduce the problem in the lab.  Windows
> 7, 64 bit, Intel(R) HD Graphics driver.
> 
Hi

Please can you indicate the version number of your driver and the exact name of your Intel chipset?

Comment 4 Dennis Cosgrove 2013-10-01 18:54:55 CEST

I have run the junit tests on the offending system.

A summary of the results of TestGearsGLJPanelAWT can be found here:

   http://www.cs.cmu.edu/~dennisc/jogl/bug838/TestGearsGLJPanelAWT.html

Note that only the default capabilities exhibit the problem.

Requesting pixel buffer, or multisampling, or bitmap all seem to get the graphics driver to behave.

I was able to "solve" the problem on our end by adding:

  caps.setPBuffer( true );

for our GLJPanels.

Is there any reason to not do this?  Should this be added to GLJPanel's constructor within the existing code below?

  // Works around problems on many vendors' cards; we don't need a
  // back buffer for the offscreen surface anyway
  {
    GLCapabilities caps;
    if (userCapsRequest != null) {
      caps = (GLCapabilities) userCapsRequest.cloneMutable();
    } else {
      caps = new GLCapabilities(GLProfile.getDefault(GLProfile.getDefaultDevice()));
    }
    caps.setDoubleBuffered(false);
    offscreenCaps = caps;
  }



bonus note 1: the results of the junit tests are available via http://www.cs.cmu.edu/~dennisc/jogl/bug838/results/

bonus note 2: the junit tests eventually threw an exception: http://www.cs.cmu.edu/~dennisc/jogl/bug838/test_run_error.txt

Comment 5 Dennis Cosgrove 2013-10-01 18:56:51 CEST

(In reply to comment #3)
> (In reply to comment #0)
> > We have received multiple reports of strangely colored graphics output from
> > the field.
> > 
> > We have a machine on which we can reproduce the problem in the lab.  Windows
> > 7, 64 bit, Intel(R) HD Graphics driver.
> > 
> Hi
> 
> Please can you indicate the version number of your driver and the exact name
> of your Intel chipset?

I sadly have limited access to this machine.  I will report the complete details the next time I have the opportunity.

Comment 6 Dennis Cosgrove 2013-10-05 01:05:52 CEST

(In reply to comment #4)
> I was able to "solve" the problem on our end by adding:
> 
>   caps.setPBuffer( true );
> 
> for our GLJPanels.
> 
> Is there any reason to not do this?  Should this be added to GLJPanel's
> constructor within the existing code below?

one reason not to do this is pixel buffers have a serious problem on linux (getWidth and getHeight do not seem to work correctly which will be the subject of a future bug report).

Comment 7 Sven Gothel 2013-10-05 14:54:29 CEST

Dennis .. can you still reproduce the bug w/ latest build, i.e.

maven 2.1.0-rc-20131004
http://jogamp.org/deployment/archive/master/gluegen_726-joal_484-jogl_1098-jocl_854
http://jogamp.org/deployment/archive/master/gluegen_726-joal_484-jogl_1098-jocl_854-signed/

?