On 27 June 2013 14:03, Alberto Mardegan <ma...@users.sourceforge.net> wrote:
> 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: > It only consists of NodeView (and variants for the different Qt widget/graphics systems) at the moment. Regarding Qt bindings for GEGL itself what I had in mind was (from README.txt): "QML Gegl bindings - Use GObject Introspection + Smoke GObject to provide Qt bindings, so that Gegl can be used in pure QML" Smoke GObject is not in a good shape though. I did a bunch of work on it late 2011 to try to bring it up to speed, but it still needs work to be able to generate QML modules. Noone else seems to have an interest in it... So if you would like to hand-write some Qt wrappers, you are free to do that in the gegl-qt repository. I would like that to be clearly separated from the current Qt widgets API though, so please put it in a separate namespace or .so and source folder. > > 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-by-one will likely be fine, though batched might be better. If you really would like to know the performance impact, I say: write a benchmark. > > > 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? The NodeView widgets in gegl-qt handles processing of the attached graph for you, so having the changes visible in real-time should already just-work. But yes, when changing properties on a node in a graph, the invalidation of that node travels along the graph until it hits the edges. -- Jon Nordby - www.jonnor.com
_______________________________________________ gegl-developer-list mailing list gegl-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gegl-developer-list
