Re: [clutter] switched colour channels
Hi Phil, On Phil gut@gmail.com wrote: I have compiled Clutter 1.2.5 with the eglnative/gles backend. The colour channels of textures seem to be switched when the format is not RGBA. This is my fault. Before Clutter 1.2 we would always convert the texture using the Cogl bitmap code when a Cogl texture is created with a different internal format from the image format. However for 1.2 I changed it so that it would just pass the image format and the internal format directly to GL so that the GL driver could do the conversion. The assumption is that the GL driver is likely to be faster (or at least our code isn't at all optimized so it can't be any slower) and support more formats. I didn't realize that GLES doesn't support the format conversions when uploading data so of course it broke for that backend. I've attached a couple of patches to the bug report¹ which should hopefully fix the problem. Furthermore, can anybody tell me where the convertion should be triggered ideally? As far as I have seen, the _cogl_texture_prepare_for_upload () seems to be the right place. There also, the GL pixel format conversion is invoked, which in turn is performed by the gles specific function. However, I am wondering why no conversion is triggered there when the CoglPixelFormat does not match the GL internal format (since the OpenGL ES does not provide the necessary conversion)? Yes, that looks like the right place and it is indeed where I've put the conversion in the patches. Thanks for the report - Neil ¹ http://bugzilla.openedhand.com/show_bug.cgi?id=2059 -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] switched colour channels
On 04/21/2010 07:35 AM, Phil wrote: Hello, I have compiled Clutter 1.2.5 with the eglnative/gles backend. The colour channels of textures seem to be switched when the format is not RGBA. I have noticed the following: * if the texture is loaded from a file (e.g. PNG) it works fine (gdk-pixbuf is used). gdk-pixbuf uses RGBA as internal format. Thus, I think it works in contrast to the other cases below. * If I load data from memory using clutter_texture_set_from_rgb_data () the issue with the switched red and blue colour channel appears. The flag CLUTTER_TEXTURE_RGB_FLAG_BGR does not seem to have an effect. * If the texture is a cairo texture (cairo uses ARGB internally) the same problem is present. I've noticed this as well, and for this reason we're sticking with clutter 1.0.x for our project. It seems there are quite a few regressions to the GLES backend in 1.2 (not to mention that the eglx backend doesn't work[1]). I've been meaning to find time to try to categorize the problems and file bugs, but I've been far too busy. Glad someone else has noticed the reversed color channel problems, though... -brian [1] http://bugzilla.o-hand.com/show_bug.cgi?id=2056 -- shame no one's looked at my patch. -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] switched colour channels
Hello, I have compiled Clutter 1.2.5 with the eglnative/gles backend. The colour channels of textures seem to be switched when the format is not RGBA. I have noticed the following: * if the texture is loaded from a file (e.g. PNG) it works fine (gdk-pixbuf is used). gdk-pixbuf uses RGBA as internal format. Thus, I think it works in contrast to the other cases below. * If I load data from memory using clutter_texture_set_from_rgb_data () the issue with the switched red and blue colour channel appears. The flag CLUTTER_TEXTURE_RGB_FLAG_BGR does not seem to have an effect. * If the texture is a cairo texture (cairo uses ARGB internally) the same problem is present. You may also compare an open bug report, where a code example is provided: http://bugzilla.openedhand.com/show_bug.cgi?id=2059 I had a look at the source code and I assume that at some point the _cogl_bitmap_fallback_convert () function should be invoked, because OpenGL ES does only accept the GL_RGBA format type (and does not provide convertion facilities). However, the function is not called. I am wondering if other people experience similar problems like me and the person who opened the bug report? Furthermore, can anybody tell me where the convertion should be triggered ideally? As far as I have seen, the _cogl_texture_prepare_for_upload () seems to be the right place. There also, the GL pixel format conversion is invoked, which in turn is performed by the gles specific function. However, I am wondering why no conversion is triggered there when the CoglPixelFormat does not match the GL internal format (since the OpenGL ES does not provide the necessary conversion)? I would be glad for any help! Phil
