Hi Jon, On 06/27/2013 01:46 PM, Jon Nordby wrote: > which gegl Qt bindings are you referring to? These ones: https://git.gnome.org/browse/gegl-qt/ At the moment they mostly consists of the NodeView, but I'd like to extend them so one could write stuff like this: Slider { id: brightness } Slider { id: contrast } Node { Node { id: brightnessOp operation: "brightness-contrast" brightness: brightness.value contrast: contrast.value } Node { id: textOp operation: "text" string: "Hello World!" } Link { input: textOp inputPad: "output" output: brightnessOp outputPad: "input" } } And then have the output image re-processed whenever the user operates the brightness or contrast sliders. So, when defining a QML Node, I don't know in advance which properties it supports (it depends on the operation, for instance); when the QML Node sees that a property is changed (or set), it should forward the information to the underlying GeglNode. Especially when a QML Node is first constructed, there'll be a bunch of node properties to be set on the GeglNode at the same time (in the brightnessOp above, these will be "operation", "brightness" and "contrast"). So, I wonder, is it fine to set these properties one by one, or is it better to batch the changes? > One thing I'm concerned about is the lack of a gegl_node_setv()-like > method, which would allow to set a list of properties on a node at once > (I'm aware of gegl_node_set(), but that's unsuitable for language > bindings). > So the question is: is calling gegl_node_set_property() multiple times > exactly equivalent to a single call to gegl_node_set() containing all > the properties, or are there performance issues? > I see that gegl_node_set_va() calls g_object_{freeze,thaw}_notify(), > what is that needed for? > > There is gegl_node_set_valist() I cannot use *_valist, because I won't have a va_list. All I will get is a GHashTable of properties-values. A method which takes a GHashTable of properties would be most convenient (see for instance how libsecret has secret_password_store() and secret_password_storev()). > Does setting a property have any immediate effect on the rendering, or > does that happen only when gegl_node_process() is called? > Could the order of setting properties have any effect on the rendering > results or performance? > > Setting properties on a node in a graph invalidates the graph. > Computing/rendering the invalidated regions is done as a separate step, > and it is the application code which controls this. So whether multiple > invalidation are coalesced or not depends on that code. Nice. Is the "invalidated" state propagated to all the nodes connected to the changed node? So, if I expose the "invalidated" signal to QML, I could do something like: // this is the final node in the graph Node { onInvalidated: process() } and have the changes visible in real-time, right? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! _______________________________________________ gegl-developer-list mailing list gegl-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gegl-developer-list
