On 27 June 2013 09:15, Alberto Mardegan wrote:

Hi all!
I don't know when (or even "if") I'll start working on that, but I'm considering extending the gegl Qt bindings to include almost everything which is currently available to the C/glib bindings, so that a developer writing an application using gegl in Qt wouldn't have to use the C/glib API at all.

Hi Alberto,
which gegl Qt bindings are you referring to?

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()

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.

Jon Nordby - www.jonnor.com

On Thu, Jun 27, 2013 at 3:46 AM, Jon Nordby wrote:

On 27 June 2013 09:15, Alberto Mardegan wrote:

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.

To clarify this, if you set properties one at a time it will invalidate the graph once for each property. If a property changes the size of the node's output you may end up invalidating more than would otherwise be necessary, but it shouldn't be a huge cost.

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

Sorry, mail went off list.

---------- Forwarded message ---------- From: Jon Nordby
Date: 28 June 2013 01:07
Subject: Re: [Gegl-developer] Qt bindings and gegl_node_set* To: scl

On 27 June 2013 21:19, scl wrote:

On 27.06.13 at 09:15 AM Alberto Mardegan wrote:

Hi all!
I don't know when (or even "if") I'll start working on that, but I'm considering extending the gegl Qt bindings to include almost everything which is currently available to the C/glib bindings, so that a developer writing an application using gegl in Qt wouldn't have to use the C/glib API at all.

Hi Jon,

as it seems some movement is coming back to that project. If you want to track the current building state, you can look at https://gimptest.flamingtext.**com:9090/view/GEGL/job/gegl-** qt-distcheck-master/

Hi Sven,
sorry for the project not being in a CI-friendly state at the moment. I am in the middle of a critical project at work, doing 60 hour+ weeks, and will be until end of next week.
So not sure if I will find time to fix up your comments before that.

Anyone who wants to fix up the things underneath before I get to it have my full blessing to push the fixes directly to master. With that being said, it would be nice if the Jenkins job could also trigger on a "for-master", "integration" or "test" branch, if people would like to test their changes outside of master.

1)

Currently the project depends on GEGL 0.2, the latest GEGL master branch has version 0.3. I don't know whether gegl-qt will work with it, so I leave it up to you to update the gegl-qt project. Let me know if you update it, so I can update the Jenkins build job.

Yes, it needs updating before that change can be made.

2)

Another thing it that error 'qml-paint.cpp:19:42: fatal error: examples/common/paint-engine.**h: No such file or directory' that breaks the build. Can you fix it to make the new contributor able to work on that project?

This is likely an easy fix. I suspect that the problem is merely the file not being distributed in the tarball, or that the directory is not on the include path when the examples are built from the tarball.

3)

Currently I'm setting the environment variables

export PRODUCT_NAME=gegl-qt-master export PREFIX="$COMMON_PREFIX/$**PRODUCT_NAME" export BABL_PREFIX="$COMMON_PREFIX/**babl-master" export GEGL_PREFIX="$COMMON_PREFIX/**gegl-0-2" export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal -I $GEGL_PREFIX/share/aclocal -I $BABL_PREFIX/share/aclocal $ACLOCAL_FLAGS" export CPPFLAGS="-I$PREFIX/include -I$GEGL_PREFIX/include -I$BABL_PREFIX/include $CPPFLAGS"
export LD_LIBRARY_PATH="$PREFIX/lib:$**GEGL_PREFIX/lib:$BABL_PREFIX/** lib:$LD_LIBRARY_PATH"
export LDFLAGS="$LDFLAGS -L$BABL_PREFIX/lib -L$GEGL_PREFIX/lib -L$PREFIX/lib"
export PATH="$PREFIX/bin:$GEGL_**PREFIX/bin:$BABL_PREFIX/bin:$**PATH" export PKG_CONFIG_PATH="$PREFIX/lib/**pkgconfig:$GEGL_PREFIX/lib/** pkgconfig:$BABL_PREFIX/lib/**pkgconfig:$PKG_CONFIG_PATH" export XDG_DATA_DIRS="$PREFIX/share:$**GEGL_PREFIX/share:$BABL_**PREFIX/share:$XDG_DATA_DIRS"

export TARBALL_NAME="$PRODUCT_NAME.**tar.bz2"

Are they all necessary or is anything missing?

ACLOCAL_FLAGS should not be necessary. CFLAGS, LDFLAGS probably should not be set, as we look up that info using pkg-config. It would be nice if GI_TYPELIB_PATH was also set, case we add tests for the introspection stuff. Should be "$GEGL_PREFIX/lib/girepository-1.0/" or somesuch (where the gegl .typelib files end up when built with introspection)

Thanks for your efforts!

Jon Nordby - www.jonnor.com



-- 
Jon Nordby - www.jonnor.com

On 28 June 2013 01:07, Jon Nordby wrote:

On 27 June 2013 21:19, scl wrote:

On 27.06.13 at 09:15 AM Alberto Mardegan wrote:

Hi all!
I don't know when (or even "if") I'll start working on that, but I'm considering extending the gegl Qt bindings to include almost everything which is currently available to the C/glib bindings, so that a developer writing an application using gegl in Qt wouldn't have to use the C/glib API at all.

Hi Jon,

as it seems some movement is coming back to that project. If you want to track the current building state, you can look at https://gimptest.flamingtext.**com:9090/view/GEGL/job/gegl-** qt-distcheck-master/

Hi Sven,
sorry for the project not being in a CI-friendly state at the moment. I am in the middle of a critical project at work, doing 60 hour+ weeks, and will be until end of next week.
So not sure if I will find time to fix up your comments before that.

Anyone who wants to fix up the things underneath before I get to it have my full blessing to push the fixes directly to master. With that being said, it would be nice if the Jenkins job could also trigger on a "for-master", "integration" or "test" branch, if people would like to test their changes outside of master.

1)

Currently the project depends on GEGL 0.2, the latest GEGL master branch has version 0.3. I don't know whether gegl-qt will work with it, so I leave it up to you to update the gegl-qt project. Let me know if you update it, so I can update the Jenkins build job.

Yes, it needs updating before that change can be made.

2)

Another thing it that error 'qml-paint.cpp:19:42: fatal error: examples/common/paint-engine.**h: No such file or directory' that breaks the build. Can you fix it to make the new contributor able to work on that project?

This is likely an easy fix. I suspect that the problem is merely the file not being distributed in the tarball, or that the directory is not on the include path when the examples are built from the tarball.

Ok, these two things should be fixed in master now. There were some changes in how graph invalidation is done in gegl master, so the interactive updates may not work correctly. That, and I found some code lying around in my git repo with some changes to the processing code... I pushed that to the "temp" branch in case anyone needs it.

Sleepytime!

Jon Nordby - www.jonnor.com

On 28.06.13 at 02:19 AM Jon Nordby wrote: > Ok, these two things should be fixed in master now.

Thank you Jon, for fixing it so quickly despite your own strained situation.

With that being said, it would be nice if the Jenkins job could also trigger on a "for-master", "integration" or "test" branch, if people would like to test their changes outside of master.

Yes, it's a good idea to have separate branches for work in progress and to merge only a finished state into the 'master' branch. I propose to name them 'feat-$Featurename'. It's similar in GIMP and GEGL: the GSOC work is done in separate branches that start with 'soc-'. If I see such branches in GEGL-Qts Git repo, I can create new Jenkins build jobs for them.

Kind regards,

Sven