I’m trying to use the color matrix from the GL_SGI_color_matrix extension. According to some documentation I’ve found (http://developer.3dlabs.com/documents/GLmanpages/glmatrixmode.htm) , the correct enum to send to glMatrixMode(mode) is GL_COLOR_MATRIX_EXT . But JOGL is only showing me something called GL.GL_COLOR_MATRIX . I tried using that as the matrix mode on a card that supports GL_SGI_color_matrix, and it gives me an OpenGL error, claiming that GL.GL_COLOR_MATRIX is an INVALID_ENUM. What’s going on here? Has the color matrix functionality been subsumed and built into OpenGL ? The card definitely reports that it does support GL_SGI_color_matrix extension, but it’s only on OpenGL 1.3 or so… if the the color matrix is built into later versions of OpenGL, maybe the problem is that the enum is different then that for the extension enum…?
I think you should be using glMatrixMode(GL_COLOR).
That seems to work, although I can’t test it because of a different issue… I’m trying to use the color matrix to manipulate the colors in an image I’m rendering to the frame buffer. If I understand the color matrix correctly, it applys only to pixel transfer operations, but I don’t want to copy to main memory, because that’s relatively slow. Instead, I’m just doing glCopyPixel(), which in principle should only operate in video memory. The problem is, it’s EXTREMELY slow, in fact, much slower than if I copy all the pixels to CPU memory, manipulate them with software, and copy them back, which doesn’t seem right. Is there something else that slows down glCopyPixels() that I can work around?
Try not enabling that or any other OpenGL state bits and see if you get the performance back. If you do, slowly re-enable things until you’ve isolated the cause of the slowdown. With ATI hardware in particular I’ve found that there are significant performance cliffs it’s easy to fall off of.
After a little bit of experimentation, I’ve determined that it isn’t the color matrix at all - copying from one buffer to the same buffer is apparently very slow (e.g. at least 1000X slower than from one buffer to another). This seems strange, but not a serious problem, as I can just write to aux buffers or Pbuffers and copy from there. Still, it seems strange that a buffer can’t self-copy without such a gigantic delay (at least on my test machine).
In a related note, will gl.isExtensionAvailable(“GL_SGI_color_matrix”) return true if I have an OpenGL Version that supports the builtin version of GL_COLOR ? I’m not sure what version this was added in (I know its there in 2.0, but I’m not sure about anything before), otherwise I suppose I could just directly check the version.
Yes, I think this is a known issue with some vendors’ drivers which came up in the implementation of the Java2D OpenGL pipeline as well. Your workaround sounds like the right thing to do.
From examining glext.h I think you need to check for the availability either of the GL_SGI_color_matrix or the GL_ARB_imaging extensions.
Ok, well, that’s unfortunate… I wish there was some way to know if it is slow, and use it only when necessary… Oh,well, I guess its the dreaded “implementation specifeic.”
Also, is there a way to call glCopyPixels() and have it read/write from a PBuffer to the main frame buffer, or do I have to read from the PBuffer to a texture and then draw to a framebuffer screen-filling rectangle with the texture on it?
To the best of my knowledge there’s no way to copy directly from a pbuffer to the main frame buffer. The GL_EXT_frame_buffer_object extension is designed to address some of these issues.
I’ve been meaning to take a look at FBOs when I get some time, anyway, although given that I’m mostly writing this as a compatibility technique for older hardware, I’m not sure how useful it’ll be.
It seems like you aren’t thanked often enough at the end of threads despite pretty much always answering the question… so thanks, Ken