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

[Jon Nordby <jononor gmail com>]

On 27 June 2013 14:03, Alberto Mardegan <mardy 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