Re: [clutter] clutter_actor_animate: assertion `duration 0' failed
Daniel Hughes tramps...@gmail.com wrote: I am playing around with clutter and am using if from c#. Because the c# bindings are in a poor state I am having to create my own bindings as I go. clutter_actor_animate is a hard call to interop because it has a variable number of arguments (something not supported in c#). Are you literally binding the clutter_actor_animate function? That's not recommended. I think the idea is that bindings would bind the clutter_actor_animatev function instead which does not take a variable number of arguments. clutter_actor_animate is intended as the C 'binding' for clutter_actor_animatev which just provides a convenient interface. Other languages are expected to bind clutter_actor_animatev separately using whatever method makes sense. For example, the Ruby bindings take a hash as the last argument which it then converts into two separate arrays (one for the property names and one for the values) to pass to clutter_actor_animatev. Calling it from Ruby then looks like this: some_actor.animate(Clutter::LINEAR, 1000, x = 100, y = 100) Maybe if C# supports array literals or hash literals it could do something similar. However I have something which I think will work, (based on the example code I have seen). But when I try to use it I am getting the following assertion. [clutter] clutter_actor_animate: assertion `duration 0' failed I have debugged it and checked that I am passing a value for duration which is valid ( greater then zero). So before I spend a lot of time trying to debug the interop I wanted to check that their was not a known issue with the clutter_actor_animate function. I don't think there are any known problems with the duration. You may want to try posting a code snippet of your binding and someone with knowledge of C# may be able to help. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] RFC: Are toggle references needed for CoglHandle ?
Hi
I've started looking at the Ruby bindings for Clutter and I was
wondering about how best to bind CoglHandles. Currently they are just
wrapped as a boxed type. This has the effect that every time you query a
property that is a CoglHandle then the result appears as a completely
new object to the eyes of the interpreter. For example:
# This creates a new ClutterTexture
irb(main):003:0 tex = Clutter::Texture.new(redhand.png)
= #Clutter::Texture:0x86070c0 ptr=0x86580a8
# This queries the 'cogl_texture' property which returns the boxed
# CoglHandle.
irb(main):005:0 handle1 = tex.cogl_texture
= #Cogl::Texture:0x85d8190 ptr=0x8649db8 own=true
# If we query it a second time we can see that we've got a different
# object
irb(main):006:0 handle2 = tex.cogl_texture
= #Cogl::Texture:0x85d4610 ptr=0x8649db8 own=true
irb(main):008:0 handle1.object_id
= 70172872
irb(main):009:0 handle2.object_id
= 70165256
This isn't a major problem but it does mean that you can't attach data
to the Ruby object or subclass it and expect it to survive if you set it
as a property. Eg:
# Create a new Cogl texture
irb(main):010:0 handle = Cogl::Texture.new(redhand.png)
= #Cogl::Texture:0x85c574c ptr=0x86400b8 own=true
# Set some data on it
irb(main):021:0 handle.instance_variable_set(:@some_data, [1,2,3])
= [1, 2, 3]
# Put it in the ClutterTexture
irb(main):023:0 tex.cogl_texture = handle
= #Cogl::Texture:0x85c574c ptr=0x86400b8 own=true
# If we query it back out then the data is lost
irb(main):024:0 tex.cogl_texture.instance_variable_get(:@some_data)
= nil
Recently Cogl in git has gained support for attaching arbitrary user
data to any handle using a pointer as a key in much the same way as
Cairo does. We could use this to attach the Ruby proxy object to the
handle so that it could return the same object every time the handle is
seen. However if we do this then we need to resolve the issue that both
the proxy object and the GObject will need to reference each other yet
we still want them to be garbage collected. Most languages that bind
GObject seem to use toggle references to fix this. So my question is,
should we add toggle reference support to CoglHandles?
I think for languages with a mark-sweep garbage collector (like Ruby) we
could get away without toggle references if the reference count on the
handle was publicly visible. I would imagine you would then need to
store a list of all GObjects that Ruby has ever seen and then during the
mark phase you simply need to walk the list and mark any objects that
have a ref count 1 (meaning something in GLib-land is also using the
object). However my hunch is that this isn't sufficient for languages
that use ref-counting for their own garbage collection because then
there'd be no equivalent of the mark phase.
CoglHandles are pretty similar to GstMiniObjects and cairo's object
system as far as I can tell. How is binding handled for those? As far as
I can tell for cairo Python just creates a new wrapper object each time:
surface = cairo.SVGSurface('out.svg', 100, 100)
cr = cairo.Context(surface)
source1 = cr.get_source()
source2 = cr.get_source()
id(source1)
3078983840L
id(source2)
3078983856L
Ruby seems to use Cairo's user data retain the proxy object, but looking
at the code I can't work out why this doesn't cause a leak (maybe it
does).
irb(main):002:0 surface = Cairo::SVGSurface.new('out.svg', 100, 100)
= #Cairo::SVGSurface:0xb764ce4c
irb(main):003:0 cr = Cairo::Context.new(surface)
= #Cairo::Context:0xb764a228
irb(main):004:0 source1 = cr.source
= #Cairo::SolidPattern:0xb7648270
irb(main):005:0 source2 = cr.source
= #Cairo::SolidPattern:0xb7648270
irb(main):006:0 source1.object_id
= -609074888
irb(main):007:0 source2.object_id
= -609074888
Both cairo and GstMiniObject publicly expose the ref count. Would this
be enough for bindings?
Any help is much appreciated.
Regards,
- Neil
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Text Font issue with Clutter 1.0.10
Nirmalya Barat barat.nirma...@yahoo.com wrote: I want to apply the related fixes on top of our clutter version off 1.2.8. Which are the ones I should pick up among these to fix the font issue? I would strongly recommend just using the branch directly because there are only minor bugfixes on that branch, but if you are sure you just want to apply the patches instead I would recommend these patches at a minimum: 080187e update backend to use lazy context/stage creation 23de53f clutter-backend-egl: Create a dummy X window and EGL surface e9d24b3 fix case when EGL driver doesn't support EGL_NATIVE_VISUAL_ID 040c240 clutter-stage-egl.c: Don't call eglWait*() 5abb2fe clutter-backend-egl: Chain up in dispose before destroying the context Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Text Font issue with Clutter 1.0.10
Nirmalya Barat barat.nirma...@yahoo.com wrote: I tried clutter 1.2.8 same issue persists. Do you know anything related fixed in 1.2.10? Yes, the fixes for the eglx backend unfortunately were too late for the 1.2.8 release so they aren't in any release yet. If you are able to clone the git repo and use the clutter-1.2 branch then you will get the patches or you can wait for the 1.2.10 release (which might happen sooner if you hassle Emmanuele Bassi :). - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] gnome-shell crashes using clutter git master repository
I could also replicate the problem on an nvidia box and I've pushed the patch below which seems to fix it. test-conformance was also failing on nvidia. I messed up the texcoord array caching patch so it wasn't disabling arrays properly and it would probably end up reading stale memory in glDrawArrays. Presumably we were getting away with this on Mesa. commit 401892af1188073dc3107832b8e2e908c5c0e79e Author: Neil Roberts n...@linux.intel.com Date: Thu May 27 14:51:44 2010 +0100 cogl: Record new enabled arrays in _cogl_disable_other_texcoord_arrays When _cogl_disable_other_texcoord_arrays is called it disables the neccessary texcoord arrays and then removes the bits for the disabled arrays in ctx-texcoord_arrays_enabled. However none of the places that call the function then set any bits in ctx-texcoord_arrays_enabled so the arrays would never get marked and they would never get disabled again. This patch just changes it so that _cogl_disable_other_texcoord_arrays also sets the corresponding bits in ctx-texcoord_arrays_enabled. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Sprite Animations
On Sun, 16 May 2010 14:31:30 -0400, Sam Wilson tecywiz...@hotmail.com wrote:
Hello knowledgeable clutter people,
I created an actor to handle drawing sprite based animations, and I am
wondering if it is the correct way to do it.
The code is written in Vala, but it won't compile with the stock clutter
bindings since I am using cogl_texture_new_from_sub_texture which isn't
bound. There's a patch attached to fix it.
The actor looks pretty neat to me. I just have a couple of points that
might make it slightly better.
- There's no need to override the pick method if the actor has no
children and you are just drawing the color to fill the actor's
allocation. The default implementation in ClutterActor will do this
for you.
- You might want to make a separate material for each frame that is
private to the actor and use that to render the texture rather than
using Cogl.set_source_texture. This will help Cogl optimize the
rendering better because Cogl.set_source_texture effectively ends up
editing a global convenience material which would cause a flush of
Cogl's journal. You should also use this material to implement the
opacity of the actor. So _frames would become an array of
Cogl.Materials and your init function would be something like this
(although I don't really know Vala so I'm just guessing the syntax):
_frames[i] = new Cogl.Material ();
_frames[i].set_layer(0, new Texture.from_sub_texture (...));
and then your paint method would be like this:
guint8 paint_opacity = get_paint_opacity ();
_frames[i].set_color4ub (paint_opacity,
paint_opacity,
paint_opacity,
paint_opacity);
Cogl.set_source (frames[i]);
...
- It's currently much more efficient to use Cogl.rectangle rather than
the path API to draw the texture. Cogl isn't clever enough to
recognise that the path you've created is a simple rectangle and it
ends up having to fill the stencil buffer to render the texture into
the path. Using Cogl.rectangle instead means it can just directly
submit a quad to OpenGL.
- You might want to implement the setter for the 'frame' property so
that it queues a redraw. Otherwise it would probably be difficult to
use ClutterActor.animate to animate the property. I don't know what's
the right way to do that in Vala.
Hope that helps.
- Neil
Here's my actor:
using Cogl;
public class SpriteActor : Clutter.Actor
{
private Texture _tex;
private Texture[] _frames;
public int frame_width { get; construct set; }
public int frame_height { get; construct set; }
public int n_frames { get; construct set; }
public int frame { get; set; }
private SpriteActor()
{
Object();
}
public SpriteActor.from_file(int width, int height,
int frames, string path)
throws GLib.Error
{
Object(frame_width: width, frame_height: height, n_frames: frames);
_tex = new Texture.from_file(path,
TextureFlags.NO_SLICING,
PixelFormat.ANY);
init();
}
public SpriteActor.from_bitmap(int width, int height,
int frames, Bitmap bit)
{
Object(frame_width: width, frame_height: height, n_frames: frames);
_tex = new Texture.from_bitmap(bit,
TextureFlags.NO_SLICING,
PixelFormat.ANY);
init();
}
private void init()
{
//this.notify[frame].connect(() = {queue_redraw();});
_frames = new Texture[n_frames];
for (int i = 0; i n_frames; i++)
{
_frames[i] = new Texture.from_sub_texture(_tex, i * frame_width,
0, frame_width,
frame_height);
}
}
protected override void paint()
{
Cogl.set_source_texture(_frames[frame]);
Cogl.path_rectangle(0, 0, width, height);
Cogl.path_fill();
}
protected override void pick(Clutter.Color c)
{
Cogl.set_source_color4ub(c.red, c.green, c.blue, c.alpha);
Cogl.path_rectangle(0, 0, width, height);
Cogl.path_fill();
}
}
diff --git a/vapi/cogl-1.0.vapi b/vapi/cogl-1.0.vapi
index 9f356d3..9c2c807 100644
--- a/vapi/cogl-1.0.vapi
+++ b/vapi/cogl-1.0.vapi
@@ -152,6 +152,7 @@ namespace Cogl {
public Texture.from_bitmap (Cogl.Bitmap bmp_handle,
Cogl.TextureFlags flags, Cogl.PixelFormat internal_format);
public Texture.from_data (uint width, uint height,
Cogl.TextureFlags flags, Cogl.PixelFormat format, Cogl.PixelFormat
internal_format, uint rowstride, [CCode (array_length = false)] uchar[] data);
public Texture.from_file (string filename, Cogl.TextureFlags
flags, Cogl.PixelFormat
Re: [clutter] How to mask two texture
Hi Rakesh Kumar rakesh.ku...@kpitcummins.com wrote: I have two texture one is rectangular texture and other one contains alpha texture that is non rectangular texture ,from this i would like to mask two texture and create new shape texture. How we can do this in clutter. You should be able to do this with a custom material on a ClutterTexture using multi-texturing. Assuming you have your alpha mask texture in a CoglHandle and your base texture in a ClutterTexture you can do something like this: ClutterActor *base_texture = ...; CoglHandle alpha_mask_texture = ...; CoglHandle material; /* Get the material from the Clutter texture */ material = clutter_texture_get_cogl_texture (CLUTTER_TEXTURE (base_texture)); /* Add the alpha mask as a second texture layer */ cogl_material_set_layer (material, 1, alpha_mask_texture); /* Set the combine function so that the base texture is modulated by the alpha component of the mask texture */ cogl_material_set_layer_combine (material, 1, RGBA = MODULATE (PREVIOUS, TEXTURE[A]), NULL); If you need picking to work as well then you would need to subclass ClutterTextue and override the pick method so that it draws a solid rectangle masked by the alpha texture in a similar way. You may want to take a look at Mutter¹ which does a similar thing to support shaped windows. - Neil ¹ http://ho.io/ck29 -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
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] Clutter gradient and text
Hi,
On Sam Wilson tecywiz...@hotmail.com wrote:
Hello, I hate to bother you all with trivial stuff like this, but I am
having some serious trouble finding the error in my program.
Essentially, I want to render a shape with a gradient background and a
text label, so I created an actor that has a single Text actor as a
child.
The gradient is rendered using a method similar to
http://lists.o-hand.com/clutter/1787.html written in vala and adapted to
handle angles. (Any improvements to this function would also be welcome
C: )
A screenshot of the incorrect behaviour is located at
http://sellyourvote.ca/Screenshot-test.png
I know it has something to do with the Text actor, since both rectangles
render properly if the text is turned off in both of them.
I'm having trouble compiling your Vala sample so I can't test the
theory, but my guess is that the problem is because you're not setting a
material before you paint the gradient. When you paint the first
gradient on the left you will have the material left over from whatever
was painted last in the previous scene. I think in this case that would
be the text. Text is painted using a special material that I think would
break your gradient. The second gradient works because it will use the
material left over from painting the outline.
I think all it needs is this line at the top of your draw_gradient
method:
Cogl.set_source_color({128, 128, 128, 255})
- Neil
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] append_knots() is missing from 'clutter.BehaviourPath' object
On Mon, 12 Apr 2010 00:23:41 +0200, Rune Svendsen runesv...@gmail.com wrote: I don't have much Python experience, and no clutter experience, but I simply don't understand why all the documents I read on clutter.BehaviourPath states it has several knot-functions (append_knots() etc.). But when I get to the second line in the following bit of the code: behavior = clutter.BehaviourPath(alpha) behavior.append_knots(actor.get_position()) the following error is printed to the terminal: AttributeError: 'clutter.BehaviourPath' object has no attribute 'append_knots' The 'append_knots' function was in 0.8 but it was taken away in 1.0. ClutterBehaviourPath was mostly re-designed for 1.0 so that it combined ClutterBehaviourBspline as well. ClutterBehaviourPath now animates an actor along a separate object called a ClutterPath. Any methods for modifying the path are now part of ClutterPath. I think the equivalent of something like this line: behavior.append_knots(point) would be behavior.path.add_line_to(point.x, point.y) - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Clutter Basics Question
On Mon, 5 Apr 2010, Rakesh Kumar wrote: d) I wanted to load binary shader using OpenGL ES 2.0. So does it supports binary shaders?. Cogl doesn't currently binary shaders. e) I wanted to load 3d objects and provide data to cogl_vertex_ buffer_draw().So can we some how connect this 3D object with actor?. Once you have the data in a CoglVertexBuffer you can render it as part of an actor by implementing the paint signal. This is exactly what the ClutterPLY library does. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Page flipping Question
Hi, On Fri, 26 Mar 2010 03:23:37 -0700, Rakesh Kumar wrote: I wanted to implement page flipping for my actor in clutter. The way it has been implemented in IPhone. Can it is possible. Please provide me some link if its there. I'm not sure exactly what the page flipping animation is like but have you looked at using Mx? It's a widget library on top of Clutter and it has a class called MxTextureDeform which can be used to morph textures in those kinds of ways. Chris has a nice video demonstrating it here: http://chrislord.net/blog/Software/mx-deform-texture.enlighten The mx source is available here: http://git.moblin.org/cgit.cgi/mx/snapshot/mx-0.9.0.tar.bz2 - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Profiling with UProf
On Thu, 25 Mar 2010 10:48:25 +, Stephen Kennedy wrote: Hi, I notice that you added profiling support to Clutter a while back, using a library called UProf. I would quite like to profile my Clutter-based app, but can not find any trace of the UProf library on the internet. Is it freely obtainable? UProf is available here: http://git.moblin.org/cgit.cgi/uprof/ We should probably mention that in some docs somewhere :) - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Confusing child actors behavior
Hi
(sorry if I've sent this twice, I'm having a bit of trouble with my mail
client)
On Tue, 23 Mar 2010 14:00:50 -0500, Uday Verma uday.ka...@gmail.com wrote:
I am trying to animate a sub-actor inside a ClutterActor but I can't
seem to be able to do so.
I have an actor A which contains several Bs, A is not a container but
a regular actor. I have a add method which adds B to A, and in the
process does B.set_parent (A).
1. When I do so, right after the parenting operation I set the
position and dimensions of B. The position and dimension requests are
not being regarded and according to --clutter-flags=paint, the
allocation of actor B is {0,0,0,0}. I wonder why that is when I am
explicitly setting the size and position. The only way I could get
the actor B to appear was by explicitly setting the allocation of
actor B to the desired location.
Setting the size of an actor just replaces the preferred and minimum
sizes that would be returned by get_preferred_with/height. The actor
still needs to be allocated to get an actual size. Any actor that has
children must implement the allocate method to call allocate on its
children. Your allocate method should be something like this (note I
don't know Vala so I'm just guessing):
public override void allocate (Clutter.Actor actor,
Clutter.ActorBox box,
Clutter.AllocationFlags flags)
{
/* Chain up so we still get an allocation (I don't know Vala's syntax
for this so I'll use C++) */
actor.ClutterActor::allocate (actor, box, flags);
/* Allocate all of the children at their natural size and position */
foreach (var a in children.values)
a.allocate_preferred_size ();
}
You also need to implement paint, pick, map and unmap in a similar
way. You can get away without pick if the children don't need to handle
events and it will work without map and unmap if you always add actors
after the container is mapped (but it's cleaner just to implement them).
- Neil
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] How to make texture transparent
Rakesh Kumar rakesh.ku...@kpitcummins.com writes: How we can create texture transparent or blending. I am using clutter_new_texture_from_file and want to make That texture transparent. If I understand your question correctly then you just need to do something like: ClutterActor *texture = clutter_texture_new_from_file (...); clutter_actor_set_opacity (texture, 128); That will make the texture 50% transparent. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Clutter-md2 for 1.0
Hi Reuven Wachtfogel wreu...@yahoo.com writes: I am trying to port my app from clutter 0.9 to clutter 1.0. My app uses clutter-md2 which was working in 0.9 but not in 1.0. I managed to get it to compile by adding these defines. #define ClutterUnit gfloat #define CLUTTER_UNITS_FROM_INT(x) ((gfloat)x) My simple test program runs but no model is shown. Any ideas on where I should look for the problem? Anyone manage to use clutter-md2 in 1.0? I've just pushed some patches to the git repo¹ to get it working with Clutter 1.0. If you could check whether this fixes it for you that'd be great. The project still could do with a lot more work to update it properly however. It's still using raw GL calls to render and this could be avoided now that Cogl has the CoglVertexBuffer API. The rendering is currently quite inefficient because the vertices are uploaded to GL at every render and it uses multiple draw calls. It also defines a ClutterBehaviourMD2 class which would not be neccessary if the properties on ClutterMD2 were changed so that you could use the clutter_actor_animate API. You may be interested in a similar project² I started to load PLY files instead of MD2. If your models are coming from Blender and you aren't using the animation features of MD2 you may have better luck using that library instead. It uses VBOs without any raw GL so it should be more robust and also render faster. It is also somewhat more flexible because it can render with any Cogl material rather than a fixed list of skins. There was some discussion about this on the mailing list³. I'd be very interested to know what your project is if you are able to say :) Hope that helps. - Neil ¹ git clone git://github.com/bpeel/clutter-md2.git ² http://bugzilla.openedhand.com/show_bug.cgi?id=1983 ³ http://lists.o-hand.com/clutter/3582.html -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D meshes in Clutter
Marc Garcia garcia.m...@gmail.com writes: I could make the monkey example work, and I've been playing with it with excellent results. What I couldn't make it work, is applying a texture to any PLY file. I followed your instructions, tried several models, and textures, and I always get the model painted with the solid color defined by cogl_material_set_color4ub. I used the exact code as you posted, using texture = cogl_texture_new_from_file (models/models.png, COGL_TEXTURE_NONE, COGL_PIXEL_FORMAT_ANY, error); I also checked that the texture is loaded successfully. The texturing is at least working for me. Could you double check whether your models include texture coordinates? You should be able to see by opening the model in a text editor and seeing whether it has the lines property float s and property float t. Any idea on what's wrong? In the COGL reference says that the color set in cogl_material_set_color4ub will be used when no lighting is enabled. Could be this the reason? When there is no lighting then yes, the color set in set_color4ub will be used as the vertex color. However the default layer combine combines this with the texture color - so both the texture and the material color influence the final fragment color. You would usually want to set the color to white when rendering with a texture so that it will end up as just the texture color. Also note if your model contains vertex color properties (which would be in the file as red, green and blue) then these will replace the material color. If you want to ensure that only the texture is used for the fragment color you could change the material layer combine function like this: cogl_material_set_layer_combine (material, 0, RGB=REPLACE(TEXTURE), error); Hope that helps - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D meshes in Clutter
donn donn.in...@gmail.com writes: Is there any chance of seeing that code? I've made a bug report against the clutter toys project to add the code as a standalone library called libclutter-ply. The code is in a large patch here: http://bugzilla.openedhand.com/show_bug.cgi?id=1983 So the idea is you can create a Blender model and export as PLY then get an actor out of it with: actor = clutter_ply_model_new_from_file(somefile.ply, error); If the model contains colors and texture coordinates those will be sent to GL when it renders. You can associate a texture with the model by attaching it to a material, eg: texture = cogl_texture_new_from_file(somefile.png, ...); material = cogl_material_new(); cogl_material_set_layer(material, 0, texture); clutter_ply_model_set_material(model, material); cogl_handle_unref(material); cogl_handle_unref(texture); There's an example program using the library in the patch. There's very little API so it probably wouldn't take too much time for someone in the know to write Python bindings for it. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D meshes in Clutter
donn donn.in...@gmail.com writes: This is all a good few levels above my capacity, but I am excited to see it taking place. I will have a stab at patching and compiling my own libclutter so that I can test it out. (push task -- *groan* wet-stack heading for out of cranium error at any moment.) Cool, thanks for trying it out. However, you won't need to compile your own Clutter - it's a standalone library. You just need to install the dev packages for clutter from your distro and then checkout the toys repo from here: git clone git://git.clutter-project.org/toys Then apply the patch with cd toys wget -O - http://bugzilla.openedhand.com/attachment.cgi?id=1828 \ | git am - Then compile it with: cd clutter-ply ./autogen.sh make Then you can try the example with cd example ./monkey - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D meshes in Clutter
donn donn.in...@gmail.com writes: Perfect. I see a rotating monkey. Nice model too. Yes, a frightening rotating monkey with no eyes - just what you wanted right? :) So, this code appears to work well. (I don't understand the depth testing stuff, but I don't expect to.) The depth testing stuff is needed so that the back of the monkey won't be drawn over the front. It's kind of awkward to enable depth testing from Cogl at the moment but we have plans to make this easier at some point. Would clutter-ply become a stand-alone package, from a python pov? Something like: import clutterply? Better would be: import clutter3D from clutter3D import PLYloader So we could add other means to get 3D data in over time. Yes, I'm not sure. A clutter-3d package supporting other data formats could be good. Potentially that could be a place to store other actors as well such as a ClutterSphere. I also have a ClutterMD2¹ library for loading the models from Quake2 written a while ago and it would be nice to merge that in with the PLY library. It has stagnated somewhat now though and it doesn't use the CoglVertexBuffer API. Anyway, if I am feeling particularly sharp I will start to read about how to make Python bindings and hack away at this. Any hints or links would be as honey to a tired bee! Ok, great! I don't know much about the python bindings so I can't offer any help. However if you wanted to take a shortcut you could use this evil hack and get to the C api directly from Python without any bindings: http://lists.o-hand.com/clutter/1979.html - Neil ¹ http://www.busydoingnothing.co.uk/blog/2008/06/06#AbusingClutter -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D meshes in Clutter
donn donn.in...@gmail.com writes: One thing I have only found hints about, via google, is how to break out of 2.5D and into 3D. I would like to have little 3D icons in my application. I know clutter is not geared towards this, but does anyone have some suggestions about how I could build small 'models' (with vertex colours and/or uv textures? Ideally, I would like to go from Blender out to a small file and into clutter. One thought I had was to build a model up from many little clutter.Rectangles, all placed and rotated in space to fake a model. Sounds a little demanding though. If you want to render a 3D model it would be a lot more efficient if you could use the CoglVertexBuffer API. This lets you collect for example a set of vertices with texture coordinates as a series of triangles and render them efficiently. If you want to export from Blender I would recommend using the PLY format. This is a relatively simple text or binary format that Blender supports well. There is a handy library for reading this format called RPly¹. I'm not sure how easy that would be to use from Python though. I have some code which wraps a Ply model as a ClutterActor and renders it through a CoglVertexBuffer which I've been using for a game. We may want to consider having something similar in Clutter core. - Neil ¹ http://www.tecgraf.puc-rio.br/~diego/professional/rply/ -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cogl paths from SVG
donn donn.in...@gmail.com writes: Is there any way to draw cogl paths from an SVG path string? I was thinking of going via a clutterPath (clutter_path_set_description) and somehow out to cogl. This would make drawing stuff in cogl a lot easier (and DRY because I would describe all paths in SVG anyway.) You could take a look at the code for the clutter_path_to_cairo_path function. It should be relatively easy to copy that function into your code and adapt it to call the respective cogl path functions instead. There was talk of adding a clutter_path_to_cogl_path function in Clutter but I guess it never happened. Note however the ClutterPath string description is a subset of the SVG path string. It seems to work with the strings generated by Inkscape though. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] [ANNOUNCE] Clutter Core 1.1.6 (Developers Snapshot)
Hi, I've temporarily stolen the maintainer hat from our venerable Emmanuele Bassi to bring to you the latest developer's snapshot leading up to the 1.2 release. Enjoy! Clutter 1.1.6 is now available for download at: http://www.clutter-project.org/sources/clutter/1.1/ A mirror is also available here: http://download.gnome.org/sources/clutter/1.1/ MD5 Checksums: b90f1585bffb7151d6af14f4cd369eb7 clutter-1.1.6.tar.gz e87acc83b0b62a583d05bea70600f3d6 clutter-1.1.6.tar.bz2 Clutter is an open source software library for creating fast, visually rich, portable and animated graphical user interfaces. Clutter is licensed under the terms of the GNU Lesser General Public License version 2.1. Clutter currently requires: • GLib = 2.16.0 • Cairo = 1.6 • PangoCairo = 1.20 • OpenGL = 1.3 or 1.2+multitexturing, OpenGL ES 1.1 or OpenGL ES 2.0 • GLX, SDL, WGL or an EGL Implementation • JSON-GLib = 0.8 (optional) • GDK-Pixbuf = 2.0 (optional) Depending on the platform and the configuration options Clutter also depends on: • GDK-Pixbuf = 2.0 • JSON-GLib = 0.8 Notes: • This is the third developers snapshot of the 1.1 cycle • This version is API and ABI compatible with the current stable release of Clutter • Installing the contents of this release will overwrite the files from the installation of the current stable release of Clutter • Bugs should be reported to: http://bugzilla.o-hand.com What's new in Clutter 1.1.6: o Some fixes for the Win32 backend (bug #1905). o Profiling support via the UProf library. Configure with --enable-profile to get a report after each Clutter application is run. o Improved conformance tests with coverage reports via gcov. o ClutterTexture no longer tries to read back texture data into g_malloc'd memory on unrealize (bug #1842). o The CGL_* defines from cogl-defines.h have been removed. These should not have been used by any applications, but if they were being used then please replace them either with the Cogl enums or with the appropriate GL_* enum if you are using GL directly. o Added a delete-event signal to the stage. o Fix for using cogl_rectangle with different texture coordinates for multiple layers (bug #1937). o Fix for using stencil and depth buffers in FBOs on Intel drivers in Mesa (bug #1873). o Support for subtitles in ClutterMedia. o ClutterGLX will now use an RGB visual by default. For applications (and toolkit integration libraries) that want to enable the ClutterStage:use-alpha property there is a new function: clutter_x11_set_use_argb_visual(). o Fix ClutterText to allow using Pango markup and attributes in the same actor (bug #1940). Many thanks to: Alejandro Piñeiro Damien Lespiau Emmanuele Bassi Gord Allot Halton Huo Robert Bragg Samuel Degrande Have fun with Clutter! -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Tidy for Clutter 1.xxx - any plans?
Shabaev Grigoriy gshab...@yotateam.ru writes: I’ am trying to compile and run simple Tidy list view example for Clutter 1.0.2 and it’s a great problem since Clutter API has changed a lot. I read some post concerning Tidy port for new Clutter and Emmanuele wrote: “when Clutter 1.0 has been released then we can start updating Tidy as well” Now we have Clutter 1.1.4– Do you have any plans for porting/updating Tidy for new APIs? Tidy has largely been abandoned and the code from it has morphed into NBTK which later became MX. You can get the MX toolkit from here: http://moblin.org/projects/moblin-ui-toolkit - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] How is GL_RGBA data packed into byte array
The OpenGL image format parameters are quite confusing. My possibly incorrect understanding is that the format (eg GL_RGBA) specifies the order of the components and the type (eg GL_UNSIGNED_BYTE) specifies whether that means the order in memory or the order of the bits within a larger native type. The types without numbers assign the whole type to a single component and the components are packed in increasing memory order - so yes GL_RGBA and GL_UNSIGNED_BYTE should give the regular RGBA format with the red component in the lowest address and the green component in the next address etc. The types with numbers pack all the components into a single number in order from most significant bit to least significant. So on little-endian I think you can get ARGB format with GL_BGRA and GL_UNSIGNED_INT_8_8_8_8. The A component is last so it ends up in the least significant byte which is the first byte for little-endian giving ARGB. However if you're using Cogl you can just call cogl_read_pixels with the type as COGL_PIXEL_FORMAT_ARGB_ and this will work on either endian-ness. For Cogl, the types always specify the component order in increasing memory addresses except for the 16-bit types. Confusing, isn't it? :) - Neil Mustafizur Rahaman mustaf.h...@gmail.com writes: Hi, I am facing some problem when I am reading data from OpenGL using glReadPixels (0, 0, pixmap_width, pixmap_height, GL_RGBA, GL_UNSIGNED_BYTE, fbp_original) [fbp_original is a char array[4]] Then I am trying to pass this data to Xserver using ARGB format. Now, my question is when I am saying GL_RGBA format in byte array, what does it actually mean? Is the R component be put into the LSB or onto the MSB irrespective of the endianness of the system? From the clutter_do_pick logic, i understand the R component is put into pixel[0], but somehow i got confused there. Can any one please help? Regs, Mustaf -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter][win32]
Konstantin Salavatov salava...@gmail.com writes: I've got assignment to evaluate Clutter features and abilities. Our goal: showing several video files (or streams) simultaneously with some some 3D and 2D effects applied. Like folding pages, rotating, transparency changing etc. Clutter when combined with Clutter-Gst should be able to do these things. For the page folding effect you sould take a look at Odo which is in the toys repo here: http://git.clutter-project.org/cgit.cgi?url=toys/tree/odo I was able to build v.1.0.8 using instructions from http://www.busydoingnothing.co.uk/blog/2008/07/13#ClutterWin32 but no one test run. All are stopped by not being able to locate some entry point in Cairo. Those instructions have been updated and are now available in the git repo here: http://git.clutter-project.org/cgit.cgi?url=clutter/tree/build/mingw/README If you were using the script from SVN mentioned in the old instructions then it would have downloaded an old version of Cairo so perhaps that's why it's not working. You could try rerunning mingw-cross-compile.sh using the new version mentioned in the new instructions to get a later Cairo. So my questions: 1) is Clutter already able to suit our needs? Is it already stable enough? It should technically be able to do these things I think. The windows version is not heavily tested but as far as I know it works ok. 2) where is build/msvc_2k5/ directory mentioned in the stable build of Clutter reference manual? It has been removed because it was unmaintained and hopelessly out of date. You could try the OAH build system as mentioned by Samuel Degrande in another reply if you want to build with VS. 3) where is .net support mentioned by listing c# on the title page of clutter-project? Is generating interop assembly already implemented? Unfortunately I don't know anything about the C# bindings. Anyone else? Hope that helps - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] CoglHandle to cloned group
On Tue, Sep 29, 2009 at 3:30 PM, Neil Roberts n...@linux.intel.com wrote: clutter_texture_new_from_actor should work for a group and let you get a CoglHandle for the texture and it at least works for me. Please see the attached example adaptation of your code showing a reflection. Aarto Matti aarto.ma...@gmail.com writes: Neil, thanks for the example. But hmmm, clutter_texture_new_from_actor() still doesn't handle groups for me. I receive the same warning as before: Clutter-CRITICAL **: clutter_actor_set_x: assertion `CLUTTER_IS_ACTOR (self)' failed I use have version 1.0.0, maybe it's with a bug. Maybe your driver and backend combination doesn't support FBOs? Under GL If your driver doesn't advertise the GL_EXT_framebuffer_object extension then clutter_texture_new_from_actor will always return NULL. For GLES2 it should always work but for GLES1 it won't. What platform and driver are you using? - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] CoglHandle to cloned group
Aarto Matti aarto.ma...@gmail.com writes:
It it possible to get a CoglHandle of cloned group? I found two ways
how to create a 'live' clone, with either clutter_clone_new() or
clutter_texture_new_from_actor(). But clutter_texture_new_from_actor()
seems not to work with ClutterGroup and clutter_clone_new() returns
not a ClutterTexture object. In both I can't get a proper CoglHandle.
clutter_texture_new_from_actor should work for a group and let you get a
CoglHandle for the texture and it at least works for me. Please see the
attached example adaptation of your code showing a reflection.
Note however there's currently a bug with clutter_texture_new_from_actor
which means the clone in your example will be slightly too small to
contain the label. You could workaround this by putting your rectangle
at the origin rather than at 20,20. See this for more details:
http://bugzilla.openedhand.com/show_bug.cgi?id=1825
- Neil
#include clutter/clutter.h
static void
paint_reflection (ClutterActor *actor)
{
ClutterGeometry geom;
clutter_actor_get_allocation_geometry (actor, geom);
guint8 opacity = clutter_actor_get_paint_opacity (actor);
CoglTextureVertex vertices[] =
{ { geom.width, geom.height, 0,
1, 1.0 },
{ 0, geom.height, 0,
0, 1.0 },
{ 0, geom.height * 1.8, 0,
0, 0.2 },
{ geom.width, geom.height * 1.8, 0,
1, 0.2 } };
cogl_color_set_from_4ub (vertices[0].color,
opacity, opacity, opacity, opacity);
cogl_color_set_from_4ub (vertices[1].color,
opacity, opacity, opacity, opacity);
cogl_color_set_from_4ub (vertices[2].color, 0, 0, 0, 0);
cogl_color_set_from_4ub (vertices[3].color, 0, 0, 0, 0);
cogl_set_source (clutter_texture_get_cogl_material (CLUTTER_TEXTURE (actor)));
cogl_polygon (vertices, G_N_ELEMENTS (vertices), TRUE);
}
int
main (int argc, char **argv)
{
clutter_init (argc, argv);
clutter_stage_set_color (CLUTTER_STAGE (clutter_stage_get_default ()),
(ClutterColor) { 0x00, 0x00, 0x00, 0xff });
ClutterColor actor_color = { 0xff, 0xff, 0xff, 0xff };
ClutterActor *rect = clutter_rectangle_new_with_color (actor_color);
clutter_actor_set_size (rect, 120, 100);
clutter_actor_set_position (rect, 20, 20);
ClutterActor *text = clutter_text_new_with_text(Courier 20, Hello!);
clutter_actor_set_position (text, 20, 50);
ClutterActor *group = clutter_group_new();
clutter_group_add(group, rect);
clutter_group_add(group, text);
clutter_stage_add(CLUTTER_GROUP(clutter_stage_get_default()), group);
ClutterActor* clone = clutter_texture_new_from_actor(group);
clutter_stage_add(CLUTTER_GROUP(clutter_stage_get_default()), clone);
clutter_actor_set_x(clone, 300);
g_signal_connect (clone, paint, G_CALLBACK (paint_reflection), NULL);
clutter_actor_show (clutter_stage_get_default ());
clutter_main ();
return 0;
}
Re: [clutter] Gaussian Blur
On Sun, 2009-09-13 at 01:29 -0400, john delahey wrote: I want to do 2 shader passes on an actor. I tried something like this: ... CutterActor *tex0 = clutter_clone_texture_new(offscreen_actor); clutter_actor_set_shader(tex0, shader0); CutterActor *tex1 = clutter_clone_texture_new(tex0); clutter_actor_set_shader(tex1, shader1); ... What is clutter_clone_texture_new? Did you mean clutter_clone_new? If so then that call won't help you chain shaders and it does not use FBOs. I think it should work if you replace clutter_clone_texture_new with clutter_texture_new_from_actor which does use an FBO. I haven't tested it though. What I get is tex1 is a copy of offscreen_actor with shader1 applied, while I wanted to get tex1 to be a copy of tex0 (after shader0 is applied on tex0) with shader1 applied. Am I doing something wrong? I though about doing it instead in the paint callback of an actor. There I would use COGL to create a framebuffer objects and perform the passes directly. Is it the right way to do it? That would also work and would probably be quite a nice way to do it but it would be more effort than using clutter_texture_new_from_actor. However texture_new_from_actor does a fair amount of work to set up the projection matrices and clipping stack which you could avoid if you just want to render a non-transformed texture so it may be a performance benefit. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] clutter-tutorial, animation-example bug with 1.0
On Mon, 2009-09-07 at 02:49 +0200, Pawel Suchanecki wrote: Hello, I used clutter-tutorial bulit from git on 05/09/09 and got the example code from share/doc/clutter/docs/tutorial/html/animation-example.html segfaulted. When I run it with clutter-1.0 (git built, on Ubuntu 9.04) it hits segv. Are you referring to this example? http://www.openismus.com/documents/clutter_tutorial/0.9/docs/tutorial/html/animation-example.html If so then this little bit of code is wrong: ClutterAnimation* animation = clutter_actor_animate_with_alpha (rect, alpha, x, 150, y, 150, opacity, 0, NULL); The x and y properties of ClutterActor are float so they need to be passed floating point values. Otherwise Clutter loses track of the variable args and starts reading random memory (hence the seg fault). It should be something like this: ClutterAnimation* animation = clutter_actor_animate_with_alpha (rect, alpha, x, 150.0, y, 150.0, opacity, 0, NULL); (notice the '.0' on the end of the 150s) Hope that helps. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] implement clipping instead of using stencil buffer
On Tue, 2009-09-01 at 01:01 +, jiangwei zhou wrote: we know that at present the clutter's clipping is implemented in clip plane/stencil buffer/Scissor. using stencil buffer, we can implement arbitrarily ploygonous clipping. it is one very common way to do the clipping in gles. but now ,we have a new demand to implement the clipping without stencil buffer . because in our target the clipping based on stencil buffer is very slow, unacceptable. we consider two ways. i hope other guys can give me some suggestion or new idear. 1. if only rect clipping is considered,can i clip the actor in fragment shader? the clip arear is in object coordinates, can i in fragment shader , convert the fragment coord point from clip coordinates to object coordiantes ,then using rect including algorthim to discard those not in the area? If the clip region is a rectangle, Cogl should already automatically use glScissor (if possible) or the clip planes if it is not a screen rectangle. I think the clip planes and scissor rect should be quite fast so there probably isn't any benefit to using a fragment shader in this case. Also as far as I understand, using 'discard' on a lot of GLES2 hardware is not recommended so it may even end up slower than the stencil buffer. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Manual spinning of the main loop.
On Mon, 2009-08-31 at 02:36 +0400, Samium Gromoff wrote: Good day folks, Are there plans to extend the API with main loop single-stepping, similar in style to gtk_main_iteration_do()? The need for that stems from desire to use Clutter as a backend for a higher-level UI substrate[1]. I looked into clutter-main.c and saw a reference to Fruity, which hints at least at a technical possibility of this. Can you not just call g_main_context_iteration(NULL, TRUE) directly? I think that's all gtk_main_iteration does anyway. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] implement clipping instead of using stencil buffer
On Tue, 2009-09-01 at 18:22 +0100, Emmanuele Bassi wrote: On Tue, 2009-09-01 at 18:14 +0100, Neil Roberts wrote: It might also be worth looking in to ways of avoiding clipping altogether in your application if at all possible. The only thing in Clutter core that I can think of that requires clipping would be an editable ClutterText. It is possible to change ClutterText so that it changes the vertex and texture coords rather than requiring the hardware to do the clipping. A patch was made for this a while ago in bug #833 but it was never applied because we decided it was simpler to just use GL's clipping mechanisms. not only simpler: it would also clip each editable Text to the entire leftmost (or rightmost, for RTL locales) glyph, instead of showing only parts of glyphs. also, it could only show entire lines and columns for a scrollable multi-line Text. No, that's not what it does. For glyphs that are partially obscured by the clip rect it would calculate new vertex coords and new texture coords so that it would only display a portion of the glyph. The calculation is simple because the clip rect and the coordinates are all in actor space. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] clutter_actor_animate ()
On Wed, 2009-08-12 at 17:32 -0400, Ian Walberg wrote: Can anyone point me to the list of 'properties' (and their values) that can be used with clutter_actor_animate (). clutter_actor_animate can animate any gobject property of an actor so to get the list you can look at the 'Properties' section in the docs for any ClutterActor subclass. All actors support at least the properties listed here: http://is.gd/2e6Nh But other actor subclasses may add more properties, such as the 'border-color' property of ClutterRectangle. These can be used with clutter_actor_animate as well. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] [ANNOUNCE] clutter-qt 1.0.0 - stable release
Hi everyone, clutter-qt 1.0.0 is now available for download at: http://www.clutter-project.org/sources/clutter-qt/1.0/ MD5 checksums: 656e0eaa088547c01aa6e716f84e7340 clutter-qt-1.0.0.tar.bz2 f00705fb448a54fd37d664244eebfd66 clutter-qt-1.0.0.tar.gz Clutter-QT is an integration library for using Clutter within QT. It has a QWidget subclass that contains a Clutter stage and can be used in much the same way as Clutter-GTK. Clutter-QT currently requires: GLib = 2.10.0 Clutter = 1.0.0 QT = 4.2 The official website is: http://www.clutter-project.org To subscribe to the Clutter mailing list, send mail to: clutter +subscr...@o-hand.com The official mailing list archive is: http://lists.o-hand.com/clutter/ Notes - * This is the initial release of Clutter-QT. * Despite the 1.0.0 version number this project hasn't had wide testing yet. * Bugs should be reported to: http://bugzilla.o-hand.com Many thanks for contributions from: Damien Lespiau Tomas Frydrych Denis Kenzior -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] MinGW / Msys
On Thu, 2009-07-30 at 12:57 -0400, Ian Walberg wrote: Has anyone built clutter 1.0.0 using MinGW / msys? I built it yesterday using MinGW but cross compiling from Linux and it worked fine. That blog post has now been updated and incorporated into a README in the git tree here: http://git.clutter-project.org/cgit.cgi?url=clutter/tree/build/mingw/README It should still work as far as I know. I would be interested to here if you have any problems or if the instructions aren't right any more. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Linking actors in 3D
On Fri, 2009-07-17 at 10:39 +0200, Filipe Nepomuceno wrote: I am trying to connect actors in a graph with a single line in 3D and was wondering what would be the best way to go about this. I was thinking of creating a rectangle of width=2 and height=distance between actors, and then use trig to rotate it into place. This is a very expensive solution though (if it works) because of the trig function calls and it wont show a line if it is rotated 90 degrees around the x axis. Another idea I had was to create a custom actor and use opengl calls to just draw a line. with glVertex. You can also use the Cogl path API to draw a line. This should be easier than using GL directly because otherwise you have to be careful not to conflict with Cogl's state caching of GL. So something like: cogl_path_move_to(actor_x, actor_y); cogl_path_line_to(other_actor_x, other_actor_y); cogl_path_stroke(); - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Darken Texture
On Fri, 2009-05-22 at 18:17 +0200, Jordi Hernández Puigdellívol wrote: @ NeilRoberts: The file you gave me is currently doing that? I see the test_black_texture_paint function that overrides the paint one but I can't understand it completely, does that mix the black texture depending on the opacity property? that would be exactly what I need The example combines the texture with a 50% gray color. The 0x80,0x80,0x80 part is the 50% gray color. You would probably want to change that to be a property of the object rather than a constant; then you could use it with the animation API. The opacity is not needed to implement the effect so it is just taken directly from clutter_actor_get_paint_opacity. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] 3D Models
On Wed, 2009-05-20 at 18:42 +0900, Jake Knickerbocker wrote: It's clutter-md2 by Neil Roberts: http://github.com/bpeel/clutter-md2/tree/master I sent him a patch for clutter-0.9, you may need it. Ah yes, that's the one. I pushed Roger's patch into that repo by the way, so there should be no need to apply it by hand. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] [win32] CLUTTER_GLX_TYPE_TEXTURE_PIXMAP
On Thu, 2009-04-02 at 02:19 +0200, Julien Isorce wrote: Is there something equivalent to: g_object_new (CLUTTER_GLX_TYPE_TEXTURE_PIXMAP, window, win, automatic-updates, TRUE, NULL); on win32 with clutter ? Unfortunately the Win32 backend has no equivalent to ClutterGLXTexturePixmap. I'm not aware of any equivalent to the texture-from-pixmap extension in WGL, although that doesn't mean there isn't one. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] A Question about texture image
On Thu, 2009-02-05 at 01:54 -0800, Peng Liu wrote: I am an OpenGL newbie and have a question about texture image. As I known, Open GL ES requires the use of power of 2 sized images. It seems that clutter can use any sized images as texture. How do you implement that ? Resize the image when loading it from a file? or other method? If non-power-of-two sized textures are not supported then Clutter will slice up the texture into smaller POT-sized textures and render them next to each other so they look like one big texture. Therefore one CoglTexture can represent multiple GL textures. Scaling the texture to fit a power-of-two size then drawing it at the original size is also a good idea and has advantages that it would make it easier to use shaders and the hardware repeat modes of GL. The disadvantages are that you might get artifacts and it could waste more memory. You could force Clutter to use this approach scaling the image to a POT-size outside of Clutter and then forcing the geometry to the original size with clutter_actor_set_size. - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cogl_texture_new_from_bitmap
On Thu, 2009-01-15 at 12:52 -0500, Vlad Seryakov wrote: I am using GLES 1.1 and the version from GIT does not compile because this function is not defined. I see it is used in async uploads only, so i made empty one in my program. This should now be fixed in master. Thanks for spotting. Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Texture scaling
On Wed, 2009-01-14 at 07:19 +, Dan Higham wrote:
Hi clad, correct me if I am wrong but I think you have to use
set_scale, I am sure this is the case after adding the texture to a
group and trying to resize the group.
If you call set_size on the texture actor then it *should* squish the
texture to fit into the rectangle. This works for me in the attached
example.
However if you are putting all of the icons into a group and then trying
to size them all in one call by setting the size of the group then that
won't work. ClutterGroup doesn't do any layout so it will ignore the
size you set on it.
Regards,
- Neil
#include clutter/clutter.h
int
main (int argc, char **argv)
{
ClutterActor *stage = stage, *tex;
GError *error = NULL;
clutter_init (argc, argv);
stage = clutter_stage_get_default ();
tex = clutter_texture_new ();
if (!clutter_texture_set_from_file (CLUTTER_TEXTURE (tex),
redhand.png, error))
{
g_warning (Failed to load redhand.png: %s, error-message);
g_clear_error (error);
}
/* Squash the texture into a small size */
clutter_actor_set_size (tex, 60, 60);
clutter_container_add (CLUTTER_CONTAINER (stage), tex, NULL);
clutter_actor_show (stage);
clutter_main ();
return 0;
}
Re: [clutter] Problem with foofone demo from clutter-toys
On Sun, 2009-01-11 at 11:24 +1100, Erik de Castro Lopo wrote: I'm also seeing strange things with the courasel demo. The names assoicated with the various icons have missing letters (eg D s instead of Dates and P f nc s instead of Preferences). Any clues why this is going so badly wrong? As you said in a later email, this appears to be a problem with Intel drivers. It seems that if mipmapped textures are used then updating a sub-region occasionally causes it to lose the texture data so some of the earlier glyphs in the glyph cache disappear. The problem can be avoided by disabling mipmapped text with clutter_set_use_mipmapped_text. This is discussed briefly in bug 1205: http://bugzilla.openedhand.com/show_bug.cgi?id=1205 Regards, - Neil -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] clutter 0.9 osx
On Sun, 2009-01-04 at 19:47 +0100, Arnaud VALLAT wrote: I've just move to git repository, and got following errors while trying to compile git from master branch on OSX. Never got those errors while I was using SVN repository. ... Undefined symbols: _glReadPixels, referenced from: _on_paint in test_conformance-test-mesh-contiguous.o I think the problem could be that compiler flags in CLUTTER_LIBS aren't set for the tests in the conform directory. Any chance you could try the attached patch to confirm this? The next error is still unsolved yet ... ... disable-npots.c:7:19: error: GL/gl.h: No such file or directory disable-npots is just a helper test tool to fake a system that doesn't have non-power-of-two textures it shouldn't cause any problems if it doesn't build. However, I've must made a commit to try and make it more portable (so it doesn't directly include GL/gl.h nor try to open libGL.so). Hopefully this should fix the problem. Any chance you could confirm this too? Thanks, - Neil 0001-Add-CLUTTER_CFLAGS-and-CLUTTER_LIBS-to-tests-conform.patch Description: application/mbox
Re: [clutter] Compiling/running on Vista, font rendering
On Tue, 2008-12-09 at 10:30 -0600, Keath Milligan wrote: I have clutter compiled and running on Vista (using Tor Lillqvist's GTK+ bundle), but I've run into a couple of problems: My guess is the pixel format you've ended up with is one of the 'Microsoft Generic GDI' implementations which means it's software rendering and only supports GL 1.1. So either there's something wrong the choose_pixel_format function or your system doesn't have the GL drivers installed properly. The function hasn't been tested on many systems and I've never tried it on Vista so it could be broken. There is a program that comes with the OpenGL SuperBible that lists all of the pixel formats supported on your windows installation. It would be really helpful if you could run it and send back the output. You need to download the sample binaries from here: http://www.starstonesoftware.com/OpenGL/ and then run this program in the zip: SuperBible4/examples/projects/microsoft/chapt19/GLView/GLView.exe If there are only 'GEN' type pixel formats then your installation only has the generic Microsoft software driver. Clutter refuses to use GEN drivers and tries to use 'ICD' drivers. I think there are also MCD drivers but I'm not entirely sure whether that works or not. Hope that helps - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Perl timeline questions
Hi, On Mon, 2008-12-08 at 10:41 +0100, Stéphane Esté-Gracias wrote: I'm try to use Timeline to move some graphical objects with following script, but red square does'nt move anyway. Could you I don't think it works to leave the alpha function as undef. If I change line 27 to: my $alpha = Clutter::Alpha-new($timeline, \Clutter::Alpha::ramp_inc); then it works for me. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Problems Rendering Text on Clutter 0.8
On Tue, 2008-12-02 at 15:58 -0200, Pedro Casagrande de Campos wrote: I'm having some problems when I add a second ClutterLabel to be rendered on my stage. I'm had this problem after I ported an old application from Clutter 0.6 to 0.8. I'm still not sure if this problem is occurring only on my computer (which have an i915 card) or it is a general problem. This is probably related to bug 1205: http://bugzilla.openedhand.com/show_bug.cgi?id=1205 It appears to be a bug on Intel where updating a subregion of a mipmapped texture sometimes causes it to clear the texture. In your screenshot, you can see that the only glyphs that are visible in the second label are the ones that weren't already in the first label. You should be able to work around it for now by calling: clutter_set_use_mipmapped_text(FALSE) Hope that helps. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] cogl_texture_rectangle reorders your texcoords?
On Tue, 2008-11-11 at 15:26 -0800, David Lock wrote: Does anyone know the specifics as to why cogl inverts your tex coords when theyre backward? Is that method of mirroring not supported on all hardware perhaps? This is discussed in bug #1057 [1]. The original reason it did this I think was to simplify the code for drawing sliced textures. However it should be possible for Clutter to keep the image flipped by swapping the vertex coords as well which is what the patch does. I will commit the patch later today so it should be fixed in the next release. - Neil [1] http://bugzilla.openedhand.com/show_bug.cgi?id=1057 -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] actor cloning
On Thu, 2008-11-06 at 15:25 +0200, Michael Boccara wrote: // another segment of code // this would also copy the line_wrap flag ClutterLabel* label2 = CLUTTER_LABEL(g_object_duplicate(label)); Perhaps you could implement this g_object_duplicate function by getting all of the properties of an object with g_object_class_list_properties, then getting all of the values into an array of GParameters and then creating the object with g_object_newv ? Not sure how robust that would be though so you might be better off trying to think of a different way to approach the problem. Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] gnome-shell / mutter / ARB_texture_rectangle
On Wed, 2008-11-05 at 16:36 +, Matthew Allum wrote: I could be wrong here, but I thought ATI did actually support npots sized regular textures, they just did not advertise the fact. Worth checking. When I had the ATI laptop (can't remember exactly what card it was) it did technically work with NPOTs textures even though it didn't advertise them, but it was terribly slow. test-actors literally took seconds to render a frame. Although apparently recent ATI drivers do support NPOTs but it is quite buggy [1]. - Neil [1] http://bugzilla.openedhand.com/show_bug.cgi?id=1156 -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clutter on VS9/Win32?
On Tue, 2008-10-28 at 14:57 +0100, Marcus Lindblom wrote: I've been trying to compile clutter using the vcproj-files in trunk (converted to VS2008) but I get a lot of errors, which makes me suspect that I really need to run autoconf/automake to get the headers right. Yes, the VS build files in trunk have unfortunately bit rotted and no longer work. The autotools files should work with MinGW and MSys and I have a blog post with details about how to do this [1]. However you might want to try OABuild [2] instead. This is an external project to make VS build files for the whole GTK+ stack including Clutter. It worked pretty well last time I tried it. Or, is it possible to build it with MinGW and then link to it from a C++ MSVS app? I think this should work if you do some magic with dlltool to generate a .lib file, but I haven't tried it myself. P.S. We're also keen on using the python bindings, and if the above issues get resolved, we're also willing to contribute both code and testing resources (before release ;). That would be great. I haven't heard of anyone using pyclutter on Windows, but in theory I guess it should just work. Regards, - Neil [1] http://www.busydoingnothing.co.uk/blog/2008/07/13#ClutterWin32 [2] http://people.collabora.co.uk/~oleavr/OABuild/ -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Image cropping while using clutter on screen of 240 *320
Hi, On Mon, 2008-10-20 at 19:30 +0530, dilip devaraj wrote: 2)In png file vincent-texture-only-gles-egl.cpp the image is being shown as 2 non-continuous textures.This in spite of me including in my app actor[0] = g_object_new (CLUTTER_TYPE_TEXTURE, disable-slicing, FALSE, NULL); This should be: actor[0] = g_object_new (CLUTTER_TYPE_TEXTURE, disable-slicing, TRUE, NULL); The 'disable-slicing' property defaults to FALSE so the line wasn't doing anything. I can't explain the cropping problem you are having however. It appears to work fine either with or without slicing on the PowerVR GLES simulator. Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] About COGL Path
On Mon, 2008-10-20 at 20:26 +0200, Arnaud VALLAT wrote: on my working copy of clutter / cogl, I've added two new functions which allow filling and stroking of paths with a texture. Basically it computes texture coordinates according to path points. I've done this because cogl does already everything on path such as bezier computation and so on. The major problem is that each time cogl_path_fill_with_texture is called it re-computes texture coordinates, moreover if you have lots of path on your scene, you compute each of them n times... That sounds very cool. How do you compute the texture coordinates? Does it still fill the path with the stencil buffer inverting trick? I was thinking of doing something like this before but never got around to it. My idea was to calculate the stencil buffer for the path as normal and then just draw the texture instead of a rectangle. Is that similar to what you have done? Are you able to share your patch? So, I'm also working on something else which exports path as a CoglHandle. This avoid computation of path for each new form you would make. It also allows the filling and stroking of path using a texture as above functions. With this design, everything is kept inside the handle and avoids repeated computation. It might be worth waiting until the Mesh API [1] stuff is ready before starting this. We could potentially have some kind of cogl_path_to_mesh function to get the path as a mesh instead of having to create a whole new CoglHandle type for the path. The current approach for rendering paths using the stencil buffer isn't ideal in my opinion because we need to do a full stencil buffer clear for every fill. It would be much better if we could tessellate the shape into triangles and send the geometry to OpenGL. That would also play much nicer with the Mesh API. Thanks, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Status of the python bindings
On Sat, 2008-10-18 at 22:51 +0100, Emmanuele Bassi wrote:
you can create an instance of a C GObject using the ctypes module and
possibly some syntactic sugar using a module; but no: you cannot mix a
pygobject based binding (like pyclutter) and a ctypes-based one. so your
application would either be completely using ctypes or completely using
pyclutter.
That's not strictly true. It is possible to do it with some voodoo that
I don't really understand. Please see this FAQ:
http://faq.pygtk.org/index.py?req=showfile=faq23.041.htp
Attached is an example using that to create a ClutterGLXTexturePixmap
and manipulate it as if it were a clutter.Actor
- Neil
# Ctypes helper code from
# http://faq.pygtk.org/index.py?req=showfile=faq23.041.htp
import ctypes
import sys
import clutter
import gobject
class _PyGObject_Functions(ctypes.Structure):
_fields_ = [
('register_class',
ctypes.PYFUNCTYPE(ctypes.c_void_p, ctypes.c_char_p,
ctypes.c_int, ctypes.py_object,
ctypes.py_object)),
('register_wrapper',
ctypes.PYFUNCTYPE(ctypes.c_void_p, ctypes.py_object)),
('register_sinkfunc',
ctypes.PYFUNCTYPE(ctypes.py_object, ctypes.c_void_p)),
('lookupclass',
ctypes.PYFUNCTYPE(ctypes.py_object, ctypes.c_int)),
('newgobj',
ctypes.PYFUNCTYPE(ctypes.py_object, ctypes.c_void_p)),
]
class PyGObjectCPAI(object):
def __init__(self):
addr = ctypes.pythonapi.PyCObject_AsVoidPtr(
ctypes.py_object(gobject._PyGObject_API))
self._api = _PyGObject_Functions.from_address(addr)
def pygobject_new(self, addr):
return self._api.newgobj(addr)
# Function to make a ClutterX11TexturePixmap
def make_tpm(win):
lib = ctypes.cdll.LoadLibrary(None)
ptr = lib.clutter_glx_texture_pixmap_new_with_window(win)
capi = PyGObjectCPAI()
return capi.pygobject_new(ptr)
if len(sys.argv) 2:
print(Usage: + sys.argv[0] + : winid)
exit(1)
win = int(sys.argv[1])
stage = clutter.Stage()
tpm = make_tpm(win)
# We can set properties using the regular pygobject API
tpm.set_property(automatic-updates, True)
stage.add(tpm)
# Python knows the object is an actor so we can call actor methods on it
tpm.set_x(80)
tpm.set_y(120)
print(tpm.get_gid())
stage.show()
clutter.main()
Re: [clutter] Offscreen rendering/clipping of texts under gles 2.0
On Wed, 2008-10-15 at 15:48 +0200, Michael Boccara wrote: There is a patch available for FBO support in GLES, which works pretty well as far as I tested. Note that that patch is just for GLES 2 and the original email said the application needs to run on Gles2.0. I think some GLES 1.1 hardware supports the GL_OES_framebuffer_object extension so it would probably be trivial to add it for that as well. Pe'ter, is there any chance you could check whether your hardware supports it? - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Status of the python bindings
On Thu, 2008-10-16 at 19:04 +0200, Dirk Meyer wrote:
But one question: how can a get the image data from a
texture? I know that set_pixbuf is gone and I do not need it, but I need
get_pixbuf. Is there a small piece of coding providing me that data
somehow?
The replacement way to do this using the C API is to get a handle to the
cogl texture using clutter_texture_get_cogl_texture, get the data using
cogl_texture_get_data and then create a pixbuf using that. However it
looks like pyclutter doesn't bind the cogl_texture_* functions as far as
I can see. You could try this replacement snippet which uses ctypes in
the mean time:
import gtk
from ctypes import cdll
def get_texture_pixbuf (tex):
lib = cdll.LoadLibrary(None)
cogl_tex = hash(tex.get_property(cogl_texture))
width = lib.cogl_texture_get_width(cogl_tex)
height = lib.cogl_texture_get_height(cogl_tex)
data = ctypes.create_string_buffer('\000' * width * height * 4)
lib.cogl_texture_get_data(cogl_tex,
19,
width * 4,
data)
return gtk.gdk.pixbuf_new_from_data(data, gtk.gdk.COLORSPACE_RGB,
True, 8, width, height, width * 4)
- Neil
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Proper surface hiding
On Fri, 2008-10-03 at 15:19 +0200, Jörn Reder wrote:
still playing around with Clutter I faced a problem with proper hiding
3D surfaces.
A while ago, I made a little sliding puzzle game in Clutter-Perl and it
had an effect when you completed the puzzle where the new puzzle would
rotate in while the old puzzle rotated out to look like a rotating cube.
I had the same problem of course. I solved it by attaching a handler for
the notify::rotation-angle-y and then lowering the old puzzle once the
angle was greater than 45 degrees. So it was like this:
# connect the signal
$old_puzzle-signal_connect ('notify::rotation-angle-y',
\lower_on_rotate);
# signal handler
sub lower_on_rotate
{
my ($actor) = @_;
my $angle = $actor-get_rotation ('y-axis');
if (($angle 0 $angle 315) || $angle -45)
{
$actor-lower_bottom;
$actor-signal_handlers_disconnect_by_func (\lower_on_rotate);
}
}
It might be more efficient to just use Emmanuele's approach with depth
testing though.
- Neil
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clipping, stencilbuffer
Hi, On Mon, 2008-09-29 at 14:25 +0300, Tapani Pälli wrote: Has there been any testing with clutter gles2 backend using omap3 or similiar board with SGX and clutter clipping functionality clutter_actor_set_clip()? I'm fairly confident I've tested clipping on an SGX system before and I don't remember any problems. Unfortunately I'm not able to test it again at the moment to confirm. It does however seem to work fine on the PowerVR simulator. There seems to be problems getting it to work. What would be the minimal testcase to start debugging the clipping feature and why it does not work? test-clip in the tests/ folder of the Clutter source is a fairly minimal use of clipping. Are you able to run that? You might want also want to double-check that your platform does have a stencil buffer by running one of the tests with --clutter-debug=backend and looking for a line like EGLConfig == R:5 G:6 B:5 A:0 S:8 where the 'S' part is 8. Hope that helps. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] [ANNOUNCE] Clutter 0.8.2 (core) - Stable release
On Thu, 2008-09-25 at 15:14 -0700, ere wer wrote: I just tried compiling and got an error (under win32+mingw): ... generating symbol list for `libclutter-win32-0.8.la' ../libtool: eval: line 4391: syntax error near unexpected token `|' Hrmm, that's odd. I just tried it here with Win32+MinGW and it worked fine. As far as I can see exactly the same version of libtool is distributed in 0.8.0 and 0.8.2 so it shouldn't be any different. It looks like your libtool has got configured wrong somehow so $global_symbol_pipe is empty. Maybe you could trying 'cp /bin/libtool /src/clutter/clutter-0.8.2/' to use your pre-configured system libtool? Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Drawing in the background while idle
On Thu, 2008-09-25 at 09:16 +0100, Emmanuele Bassi wrote: and while GLib data structures and MainLoop are usually thread safe, GType instantiation is not entirely thread safe (try creating two new instances of the same class from the same thread). I don't think the threading issues are so much of a problem for this simple case of calling glXSwapBuffers in a second thread. It creates one single extra thread which doesn't invoke any callbacks, call object methods nor create any objects. It only locks a mutex, waits to be woken up via a GCondition and calls glXSwapBuffers in a loop. Once the swap is completed it calls g_main_context_wakeup. I believe the wakeup is performed by sending a byte on a pipe to the main thread. So all event handling and painting is still handled by the thread that calls clutter_main. Currently, the extra thread is only created if you call g_thread_init so it won't affect apps that don't ask for it. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Drawing in the background while idle
On Thu, 2008-09-25 at 10:06 +0100, Emmanuele Bassi wrote: (I think your clock might be wrong there?) what I meant was: pushing Clutter towards a heavier threads usage, in itself is a worthy goal at that, will require some serious rethinking of how the API should interact with threads. Ok, so just to be clear, are we agreed that while that may or not be a worthy goal, it is a completely separate discussion from the glXSwapBuffers idea? The extra thread doesn't need to worry about clutter's thread model because it doesn't do any clutter calls. I think Clutter's current threading model is fine and is the same as adopted by GTK and Java/Swing (and probably others). You can do whatever you like in any threads, but all GUI calls should be done in one elected main thread (the one that calls clutter_main). It sounds like a lot of pain for very little gain to make every clutter call truly thread safe. The current model encourages you to do the sensible thing which is to use single-threading wherever possible and if you want a lengthy calculation in a separate thread you can do that, but that thread should only notify the main thread to repaint instead of doing any GUI calls directly. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Clipping problems with clutter
Hi, On Wed, 2008-09-10 at 16:27 +0300, Karoliina Salminen wrote: I have had some issues with clipping in a clutter app - the clutter_actor_set_clip does not work. This works on my laptop perfectly (it is nVidia, which has no problems as usual) but not with one another hw (using the gl-es backend), clipping has no effect (and the chip is supposed to support clipping and it is supposed to work in the driver). So, how clutter is doing the clipping on the OpenGL Es level? In 0.8, clipping is implemented either by using the clipping planes or the stencil buffer. If you have a parent actor with a clip set and then also clip the children it will use the clipping planes for the first clip and then the stencil buffer for the inner clips. In 0.6 it always uses the stencil buffer and only supports a single level of clipping. On some GL ES implementations (such as MBX) there is no stencil buffer so you can only have one level of clipping (or in 0.6 it won't work at all). Could that be the problem? You can check if you have a stencil buffer by running a clutter app with --clutter-debug=backend and checking if any EGLConfigs say S:8 - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] About tearing issues and VSYNC use with video textures
On Fri, 2008-08-22 at 19:47 +0200, Florent wrote: As bpeel suggested on the IRC, doing the glXSwapBuffers calls inside a separate thread could be of help (after all, is the FPS counts' instability suggesting a bad FPS counting or a glXSwapBuffers-related bandwidth/process limitation ?). FWIW, I finally got round to implementing this in a patch on Bugzilla [1]. However the patch needs more work to be complete because it currently breaks picking. [1] http://bugzilla.openedhand.com/show_bug.cgi?id=1118 - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] ClutterBitmap
On Wed, 2008-08-27 at 11:10 -0400, Michael Boccara wrote: What is the simplest way to render a bitmap Fonts aren't actually stored as 1-bit bitmaps in Clutter. They are rendered from the system's scalable vector format using pango/cairo/freetype. Then they are uploaded to OpenGL as 8-bit alpha channel images. The fonts are actually grayscale because they can be anti-aliased. The closest you can get to a 1-bit bitmap with your own textures is to create a cogl texture with the format set to COGL_PIXEL_FORMAT_A_8 and then upload your image as 8 bits per pixel grayscale (so you could be using 8 bits instead of 32 bits per pixel), but there is no guarantee the graphics card will store it this way and might just expand it to 32 bits anyway. Therefore it's probably best just not to worry about the memory loss and upload a 32-or-24-bit texture. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Gradient
On Wed, 2008-08-27 at 13:10 +0200, Arnaud VALLAT wrote:
I've played with cogl_texture_polygon and succeeded to render a
gradient. But I can't make a gradient from a color (blue for example)
and a clear color (black with alpha at 0) because I have filled the
texture with white. Is there a way to clear a texture ? like a memset
it ?
I'm not sure what you mean. You should be able to leave the texture as
all white and the just change the colour using the color member of
CoglTextureVertex. The final alpha drawn to the screen is the alpha of
the vertex colour multiplied by the alpha value of the texture, so at
vertices where you specify a zero alpha it should result in a fully
transparent image. Please see the attached example.
- Neil
#include clutter/clutter.h
static void
on_paint (ClutterActor *actor, CoglHandle tex)
{
ClutterActor *stage;
guint width, height;
stage = clutter_actor_get_stage (actor);
clutter_actor_get_size (stage, width, height);
{
CoglTextureVertex verts[]
= { { CLUTTER_INT_TO_FIXED (0), CLUTTER_INT_TO_FIXED (0), 0,
CFX_ONE / 2, CFX_ONE / 2,
{ 0xff, 0x00, 0x00, 0xff } },
{ CLUTTER_INT_TO_FIXED (width / 2), CLUTTER_INT_TO_FIXED (0), 0,
CFX_ONE / 2, CFX_ONE / 2,
{ 0x00, 0xff, 0x00, 0xff } },
{ CLUTTER_INT_TO_FIXED (width / 2), CLUTTER_INT_TO_FIXED (height), 0,
CFX_ONE / 2, CFX_ONE / 2,
{ 0x00, 0xff, 0x00, 0x00 } },
{ CLUTTER_INT_TO_FIXED (0), CLUTTER_INT_TO_FIXED (height), 0,
CFX_ONE / 2, CFX_ONE / 2,
{ 0xff, 0x00, 0x00, 0x00 } } };
cogl_texture_polygon (tex, 4, verts, TRUE);
}
}
int
main (int argc, char **argv)
{
ClutterActor *stage = stage;
guchar white_image_data[] = { 0xff, 0xff, 0xff, 0xff };
CoglHandle tex;
clutter_init (argc, argv);
stage = clutter_stage_get_default ();
clutter_stage_set_color (CLUTTER_STAGE (stage),
(ClutterColor) { 0x80, 0x80, 0xff, 0xff });
tex = cogl_texture_new_from_data (1, 1, -1, FALSE,
COGL_PIXEL_FORMAT_RGBA_,
COGL_PIXEL_FORMAT_ANY,
4, white_image_data);
g_signal_connect_after (stage, paint, G_CALLBACK (on_paint), tex);
clutter_actor_show (stage);
clutter_main ();
cogl_texture_unref (tex);
return 0;
}
Re: [clutter] Gradient
On Mon, 2008-08-25 at 16:30 +0200, Arnaud VALLAT wrote: I would like to make a gradient but not only on a quad ... I would like to be able to assign a color to each point of a polygon for example. You can do this with cogl_texture_polygon although it's a less than ideal solution (but it is probably still faster than using Cairo). You need to create a completely white texture (it can be any size) and draw it with cogl_texture_polygon, specifying the colours for each vertex. The colours will be blended with the colours from the texture, but as the texture is completely white you will just get the colours from the vertices. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Custom actors using GL directly
On Wed, 2008-08-20 at 10:16 +0300, Michael Boccara wrote: The problem with this workaround is that you do glGet* upon every frame, which is flushing/finishing the GL pipeline, causing performance issues. I would be very surprised if that is how glGet is implemented. It would expect it to just read from some internal struct attached to the context and it wouldn't matter whether the actual hardware has caught up to that state or not. I still don't agree with the choice of having Cogl manage a cache of the GL state. Any good OpenGL driver does this job internally in order to achieve good performance against competitors. When Cogl was rewritten, there was a point where we weren't using the cache for some part of the Pango rendering and we had a definite measurable performance impact compared to the old Cogl from calling glEnable/Disable excessively. Even if the OpenGL driver internally caches the state as well, I believe there is still some expense for any GL call to lookup the current context from thread-local storage and do an indirect function call. I haven't looked at an actual GL driver though so I'm not an expert, but this is just my experience. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] fbo support for the OpenGL ES backend
On Tue, 2008-08-19 at 23:37 +0300, Michael Boccara wrote: Is there a plan to have Cogl support offscreen rendering in the GLES 2 backend ? What would it take to contribute and implement it ? What are the expected issues ? It's fairly trivial to implement and in fact has already been done in this bug report: http://bugzilla.openedhand.com/show_bug.cgi?id=1074 I can't see any reason why this won't be landed before the next release. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] multitexture support
On Tue, 2008-08-19 at 23:41 +0300, Michael Boccara wrote: Is there a plan to add support for multitexture in Clutter ? Rob Bragg has been working on this here: http://bugzilla.openedhand.com/show_bug.cgi?id=992 I don't know when this will land in Clutter, but it is unlikely to be before 1.0. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Custom actors using GL directly
On Tue, 2008-08-19 at 23:36 +0300, Michael Boccara wrote: I tried to create a custom actors, using direct OpenGL calls in the paint override. Did anybody else hit the same problem ? I had the same problem when making the ClutterMD2 renderer. You can work around it by saving some of the GL state before doing your custom GL rendering and then restoring it afterwards. Please take a look at the clutter_md2_data_save/restore_state functions here: http://tinyurl.com/5dn3bv Is there a way to cancel Cogl's internal GL state cache ? Not at present. There was talk of providing functions in Cogl to help with this but it needs some more discussion before being implemented because it's not always obvious what state should be preserved. Sometimes you may want the GL state to be set to a known consistent state and sometimes you want some Cogl settings to remain (such as cogl_enable_depth_test or a shader). - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] API suggestion for COGL
On Wed, 2008-08-13 at 09:15 +0400, Mykhailo Parfeniuk wrote: I would like to know is there any plans to add to COGL API text rendering, gradient and texture filling for primitives. You can render text using Clutter's glyph cache if you include clutter/pangoclutter.h. You need to create your own font map with pango_clutter_font_map_new because Clutter's internal font map isn't exposed. If you keep that instance around it will work as a second cache. Then you can create a context using pango_clutter_font_map_create_context and render layouts with pango_clutter_render_layout. The API isn't documented so I'm not sure if it's officially supported yet. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] ANNOUNCE: rbclutter 0.8.0
The Ruby bindings for Clutter 0.8 are now available on RubyForge: http://rubyforge.org/projects/rbclutter/ This includes complete bindings for 0.8 including Cogl. Please try them out! If anyone can offer any help for making a Debian package so I don't have to read the friendly manual, I would be grateful. There are some issues to be aware of mentioned in the README which are pretty much the same as the last release: - There's no documentation, however the method names try to follow the same system as the Ruby GTK bindings so you can generally read the Clutter API documentation and guess the Ruby method. See this page for details: http://tinyurl.com/3btpoq - There's no way to implement an interface or override a GObject method in Ruby code yet. So for example, you can create a Ruby object that is a subclass of Clutter::Actor, register it as a new GType and create custom signals, but you can not implement the ClutterContainer interface. - There are bindings for clutter_threads_enter and clutter_threads_leave but you shouldn't need to call these functions if you are just using regular Ruby threads. Ruby does not use native threads so there is no need to lock Clutter. If you do try to grab the Clutter lock in two separate Ruby threads then the process will block forever because Ruby will not be given a chance to switch threads while waiting for clutter_threads_enter to complete. It can however be used in combination with another library that may create native threads. - The effect functions can't take a callback block for when the effect is complete, even though the C API has a parameter for it. I'm hoping Clutter will eventually get a GDestroyNotify parameter for the effect functions which would make this a lot easier. - Clutter::init isn't explictly called for you when you execute 'require clutter'. That way you can optionally use your own argument array instead of ARGV. However, there appears to be a problem wrapping clutter-gst before gst_init is called, so if you execute 'require clutter_gst' it *will* explicitly call clutter_gst_init. -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Problems with building under Windows.
On Sun, 2008-08-03 at 16:54 +0300, Mykhailo Parfeniuk wrote: I just tried to build Clutter under Windows using MSYS. And I there were compilation error because GLhandleARB and GLcharARB were not declared. The way I've been recommending to people to build the Windows backend is to use the GL headers from Mesa instead of the ones provided by MinGW. If you build using the mingw-cross-compile.sh script from the SVN repo it will download and install these headers for you. There is a description of compiling using MSyS and MinGW using that approach here: http://www.busydoingnothing.co.uk/blog/2008/07/13#ClutterWin32 - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] CLUTTER_FEATURE_OFSCREEN
On Mon, 2008-07-21 at 19:25 +0800, HASWANI HARISH-VCKR47 wrote: When off-screen feature will be supported by clutter? Are you perhaps referring to this error message? ** ERROR **: This test requires CLUTTER_FEATURE_OFFSCREEN That does not mean that Clutter does not support offscreen at all, but rather that your OpenGL implementation does not support frame buffer objects. These are required to use clutter_texture_new_from_actor. This will happen for example with an Intel chip set. Clutter also doesn't currently support frame buffer objects on GL ES. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Create array of ClutterActor
On Sat, 2008-07-19 at 09:03 +1000, Saul Lethbridge wrote:
My application will be using an unknown number of clutter actors at
build time. I'm wanting to create a struct of arrays that I can later
realloc when required.
struct cNode
{
int numNodes;
ClutterActor *clutterArray[1];
cairo_t*cr[1];
};
Using a struct with an array and overallocating to make the array longer
only really works if the array is the last field of the struct so it
won't work in this case where you are trying to have two arrays in one
struct.
The easiest way to do this would probably be to make a struct to contain
a single pair and then use a GArray [1] or a GSList [2] to keep track of
them, like this:
struct cNode
{
ClutterActor *actor;
cairo_t *cr;
};
struct cNode node;
/* make the array */
GArray *array = g_array_new (FALSE, FALSE, sizeof (struct cNode));
/* add an item */
node.actor = clutter_texture_new (...);
node.cr = cairo_create (...);
g_array_append_val (array, node);
/* add another item */
node.actor = clutter_label_new (...);
node.cr = cairo_create (...);
g_array_append_val (array, node);
/* add the first actor to the stage */
g_container_add (stage, g_array_index (array,
struct cNode, 0).actor, NULL);
/* etc */
- Neil
[1] http://library.gnome.org/devel/glib/stable/glib-Arrays.html
[2] http://library.gnome.org/devel/glib/stable/glib-Singly-Linked-Lists.html
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] gl stack overflow problem
Looking at the clutter_group_paint function, isn't it completely
unnecessary that we push and pop the matrix there? We don't change the
matrix at all in that function and each child actor will push and pop
the matrix itself before applying the transformation in
clutter_actor_paint. Getting rid of that would effectively double the
stack depth right?
- Neil
On Thu, 2008-07-17 at 14:27 +0900, 이주성 wrote:
static void clutter_group_paint (ClutterActor *actor)
{
ClutterGroupPrivate *priv = CLUTTER_GROUP (actor)-priv;
GList *child_item;
cogl_push_matrix ();
for (child_item = priv-children;
child_item != NULL;
child_item = child_item-next)
{
ClutterActor *child = child_item-data;
g_assert (child != NULL);
if (CLUTTER_ACTOR_IS_VISIBLE (child))
clutter_actor_paint (child);
}
cogl_pop_matrix ();
CLUTTER_NOTE (PAINT, ClutterGroup paint leave);
}
--
To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Tidy JSON
On Wed, 2008-07-09 at 16:07 -0700, Jeff Shulman wrote: specified class size for type `TidyActor' is smaller than the parent type's `ClutterActor' class size That sounds like you may have compiled Tidy using headers from a different development version of Clutter than the one installed. It will probably go away if you recompile and reinstall Tidy. Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Some help with Ruby and Clutter
On Fri, 2008-07-04 at 20:54 -0400, Fred Warren wrote: I'd like to try out using clutter in Ruby, testing gstreamer and gtk too. Great! As said by Reid van Melle, the last release of the Ruby bindings only covers Clutter 0.4 but I am working on updating them to 0.7/0.8. I have a git repo with my work in progress [1]. It it usable with 0.7 but not everything is bound yet. I'm hoping to complete the bindings soon. What packages I have to install to get it setup? There are no packages for the bindings that I know of so you will need to compile from source. If you install Clutter and its development package and then apt-get install libgtk2-ruby that should get you all of the dependencies needed to build. What documentation is there? None I'm afraid. The translation from the C API to the Ruby API should be fairly consistent so currently your best bet is probably to read this generic Ruby gobject documentation [2] and the use the C API docs [3]. What example files are there? There are a couple of example files in the examples/ folder of the source tree. Mainly they are ports of the tests from the Clutter source but there is also thumbnailer.rb which is an example app showing thumbnails of images. Unfortunatly I haven't yet updated it to new bindings so it won't run anymore. [1] git clone git://github.com/bpeel/rbclutter.git [2] http://tinyurl.com/3btpoq [3] http://www.clutter-project.org/docs/clutter/0.7/ -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] several questions
On Thu, 2008-07-03 at 08:54 -0400, Reid van Melle wrote: 5. Direct Usage of OpenGL Question #4 led me to try direct use of the OpenGL API within a Coglbox actor paint function. It did not seem to work as I hoped. I was just drawing a simple rectangular polygon via OpenGL... I saw the rectangle appear and then disappear very quickly in subsequent calls to the paint function. Unfortunately there is still some hoops you have to jump through to safely use OpenGL calls directly in a paint function so you may have run in to these problems. COGL changes some of the GL state (with glEnable/glDisable) when it renders textures or shapes and it caches the state so that it doesn't have to make a new GL call unless it actually needs to change the state. So if you have other actors in your scene then when your custom paint function is hit then GL will be in a different state depending on what order the actors are rendered. COGL will get confused if you don't restore the state to what it was once the paint is completed. Therefore your paint function needs to store some of the current settings of GL, set the state to what it needs, do the actual drawing and then restore the GL state. There is an example of this in the Clutter-MD2 renderer here: http://tinyurl.com/5fq6we Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter_texture_set_from_rgb_data
On Wed, 2008-07-02 at 14:28 +0800, HASWANI HARISH-VCKR47 wrote: While going through clutter_texture_set_from_rgb_data API, I found that currently clutter support only 4 BPP. will clutter 0.8 support 3BPP Clutter happily supports 3 bytes per pixel if by that you mean 1 byte for each of the R, G and B components and no alpha channel. You just need to set the has_alpha argument to FALSE. The documentation is a bit misleading there. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter_texture_set_from_rgb_data
On Wed, 2008-07-02 at 10:59 +0100, Robert Bragg wrote: One option is to use cogl_texture_new_from_data which supports more formats and also lets you control the internal format. I was just about to reply saying the same thing with this little example: cogl_tex = cogl_texture_new_from_data (TEX_WIDTH, TEX_HEIGHT, 32, FALSE, COGL_PIXEL_FORMAT_RGB_565, COGL_PIXEL_FORMAT_ANY, TEX_WIDTH * 2, (guchar *) tex_data); tex = clutter_texture_new (); clutter_texture_set_cogl_texture (CLUTTER_TEXTURE (tex), cogl_tex); cogl_texture_unref (cogl_tex); - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] clutter_texture_set_from_rgb_data
On Wed, 2008-07-02 at 08:28 -0400, Jason Tackaberry wrote: [Resending to list again; sigh, clutter is the only list I use which doesn't rewrite Reply-To :)] Can anyone fix this? I've fallen for that a few times too :( Is the 3bpp support first converted to 4bpp in software before uploading to the card, or can textures natively support this formaT? OpenGL certainly has support for uploading textures in this format but I guess potentially the driver might need to internally convert it to a different format, but at least this will always give you the fastest route. COGL lets you pick a different format for the internal texture so you can choose whether you want it to convert before uploading to the card or not. Is it possible to pass RGB32 (4bpp) but have clutter ignore the alpha channel? I don't think this is possible without having COGL convert the texture unfortunately. You essentially want to disable GL_BLEND and draw the texture but cogl_texture_rectangle enables GL_BLEND based on whether the texture has an alpha channel. You could of course make a custom actor and override ClutterTexture::paint and draw with raw GL calls but that's not so fun. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] Clutter on Windows
Hi all, I checked in some changes yesterday to make the WGL backend with the multi-stage stuff. I also fixed some bugs and actually tested it on a real WinXP box instead of just assuming it will work :) I spent a while trying to figure out why it has such low frame-rates and found that you need to call the timeBeginPeriod Windows function otherwise the glib timeouts are too imprecise. However this only has any effect with Glib = 2.16 because they changed the way it works. In the process of trying to figure that out I also noticed that the SDL backend uses 100% CPU on Windows. I think this is a bug in glib so I filed it on their bugzilla here: http://bugzilla.gnome.org/show_bug.cgi?id=525192 . I'm not sure if we want to work around that in Clutter or whether we should just wait until glib gets fixed. Another issue is that when building with MinGW libtool will refuse to build a DLL for Clutter when linking statically with GLee. This only started happening with some recent version of libtool. I think the idea is that you shouldn't put non-PIC code into a dynamic library and libtool has no way to know whether a static library is PIC or not so it resorts to building static libraries instead. However as far as I understand it Windows doesn't really do PIC code anyway and instead just has a preferred base address for DLLs and manually relocates them all as necessary. I'm not sure what to do about it it unless we do something evil like patch the version of libtool we distribute with Clutter. Or maybe we could include a cut-down version of GLee as a libtool convenience library in the Clutter source? Is there somewhere I can note these down as known issues? Regards, - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] ClutterTexture pixbuf property
Hi,
I was just wondering if there is a good reason why the 'pixbuf'
property of ClutterTexture is created with g_param_spec_pointer and
not g_param_spec_object? GdkPixbuf is a GObject derived type and it
makes it much easier to use from language bindings if you can just
directly pass a GdkPixbuf object. I've attached a patch to
demonstrate.
Regards,
- Neil
Index: clutter/clutter/clutter-texture.c
===
--- clutter/clutter/clutter-texture.c (revision 1178)
+++ clutter/clutter/clutter-texture.c (working copy)
@@ -795,7 +795,7 @@
{
case PROP_PIXBUF:
clutter_texture_set_pixbuf (texture,
- (GdkPixbuf*)g_value_get_pointer(value),
+ GDK_PIXBUF (g_value_get_object (value)),
NULL);
break;
case PROP_USE_TILES:
@@ -846,7 +846,7 @@
{
GdkPixbuf *pixb;
pixb = clutter_texture_get_pixbuf (texture);
- g_value_set_pointer (value, pixb);
+ g_value_set_object (value, pixb);
}
break;
case PROP_USE_TILES:
@@ -903,10 +903,11 @@
g_object_class_install_property
(gobject_class, PROP_PIXBUF,
- g_param_spec_pointer (pixbuf,
- Pixbuf source for Texture.,
- Pixbuf source for Texture.,
- CLUTTER_PARAM_READWRITE));
+ g_param_spec_object (pixbuf,
+ Pixbuf source for Texture.,
+ Pixbuf source for Texture.,
+ GDK_TYPE_PIXBUF,
+ CLUTTER_PARAM_READWRITE));
g_object_class_install_property
(gobject_class, PROP_USE_TILES,
