Re: [Gegl-developer] Qt bindings and gegl_node_set*

[Alberto Mardegan <mardy users sourceforge net>]

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!