On Thu, 2009-07-23 at 14:04 +0200, Vladimir Nadvornik wrote: > On ne 14. června 2009, Vladimir Nadvornik wrote: > > On Sunday 14 June 2009 13:08:25 Øyvind Kolås wrote: > > > On Sat, Jun 13, 2009 at 5:32 AM, Saul > > > > > > Lethbridge<[email protected]> wrote: > > > >> Is it possible to do something similar with clutter API? > > > > > > > > This sounds like it would be a useful addition. > > > > > > What would be the useful addition? > > > > > > I think it only makes sense to do such color correction in cases where > > > the software is part of a visual media production pipeline where both > > > source material and display devices have proper ICC profiles. (inputs > > > assumed to be in sRGB could be used). > > > > Yes. I am working on an image viewer for photos (geeqie.sf.net), where the > > color management is a must. Processing the image data with lcms is rather > > slow (around 10 MPix/s), the method with 3D lut in GPU is at least 30x > > faster. Clutter API would help a lot with image scaling, zooming, etc. > > > > > You can do similar lookup-tables with cogls API if you have a real > > > need for it, though I am not sure if you could used 3D-textures in the > > > manner required. > > > > I haven't found any possibility to use 3D textures with cogl. So the > > question is, if I can create it with opengl API and set it up in the > > second texturing unit before the ClutterTexture is drawn with a > > ClutterShader , or if there would be any conflict with clutter internals. > > > > > > Hi, > > I tried to port the original code to clutter, see the attachment. It seems to > work with 0.9.8, but I am not sure if I can rely on it.
Breaking out into raw OpenGL is inherently risky. Even if you don't conflict with Cogl internals today, we can't guarantee that you won't conflict with Cogl in the future. As far as breaking out into raw OpenGL goes the only support we currently give is via the cogl_begin_gl(), cogl_end_gl() APIs but these are only intended to help developers use raw GL for the drawing of custom Clutter actors (though their use is very much discouraged); we really can't support developers trying to change OpenGL state with the intention of modifying Cogl's behaviour. For your specific example you should be aware that Clutter and Cogl support multi-texturing via the Material API, so if you are directly fiddling with texture unit 1, you will need to make sure you don't ever use a CoglMaterial with multiple layers. The other thing to be aware of is that Cogl batches geometry internally, and provides no guarantee to Clutter that anything is really sent to OpenGL when an actor paints. That means if you bind something using OpenGL in a pre-paint, and un-bind it later you have no guarantee that Cogl will draw anything while you have modified the GL state. Worse than that; it's more likely that you will modify the GL state in your pre-paint and then cause a flush of Cogl's internally batched geometry before you restore your state, so you risk affecting the drawing for previously batched primitives. Again I wouldn't recommend this approach, but you may want to look at cogl_flush() which may be used to improve your chances of success :-) If there is functionality missing in Cogl, I would be more interested in improving Cogl than finding ways to work around it via direct GL calls. Binding 1D and 3D textures is a valid feature request for Cogl, but so far I haven't been able to work through what it would take to expose in a nice and compatible way. If you could come up with a proposal or better still patches :-) for Cogl I think that's the only way we will be able to reliably support your use-case. I hope that helps, regards, - Robert -- Robert Bragg, Intel Open Source Technology Center -- To unsubscribe send a mail to [email protected]
