Jon Nordby wrote:

CC'ing the GEGL mailing list, since there may be others interested.

On 2 July 2012 20:24, Isaac Wagner wrote:

Hey,

My name is Isaac and I'm a GSoC student this year working on a graphical node editor for gegl. I recently replaced my own dirty rendering method with gegl-gtk and it was much more convenient than what I was doing, but still seems to suffer from the key problem which originally lead me to gegl-gtk: nodes with infinite bounding boxes (such as gegl:checkboard) completely devour memory when attempting to render and never actually do succesfully render. So my question is: Is there some hidden functionality for intelligently handling infinitely-bounded nodes in GeglGtkView? If not, would you accept a patch implementing such functionality (or even give me access to the gegl-gtk tree so that I can commit the functionality myself)?

Hi Isaac,

glad to hear gegl-gtk was useful to you. I will try to check our your node editor work soon.

What exactly is the issue with nodes with infinite bounds? I have not tested myself. Rendering of gegl:checkerboard sounds like some that should just-work, so I'd be happy to accept patches if it does not.

I think the problem here is that a program like this:

#include int main (int argc, char **argv) {
gegl_init (&argc, &argv);
GeglNode *a = gegl_node_new (); gegl_node_set (a, "operation", "gegl:color", 0); gegl_node_process (a);
}

does not terminate. It creates a single color node and tries to gegl_node_process() it. But because the color node produces an infinite (virtual) image, the process node needs an infinitely long time to process it. Or at least this is the way i understand it. In its way, at least it is logical.

I think the problem here is not the process functionality, but the API; the function gegl_node_process() does not have an error return value, so it practically must not fail, and so it has to take the long path of processing for all eternity (or until it runs out of memory, whatever happens first).

If you have commit access to GEGL, you should have commit access to gegl-gtk. You can create a branch with proposed fixes there and I'll have a look.

I also have some interest in implementing the background node rendering (or using someone else's implemention) that I saw mentioned in the comments. It would be nice to show a checkerboard underneath alpha transparency in the node previews in my editor.

Background rendering should already be possible by connecting to the GeglGtkView::draw-background signal. See for instance examples/c/gegl-gtk-paint.c in the source tree

Thanks!

Isaac

--
Jon Nordby - www.jonnor.com
_______________________________________________ gegl-developer-list mailing list
gegl-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gegl-developer-list

On Tue, Jul 03, 2012 at 01:28:38AM +0200, rassahah@googlemail.com wrote:

Jon Nordby wrote:

CC'ing the GEGL mailing list, since there may be others interested.

Hi Isaac,

glad to hear gegl-gtk was useful to you. I will try to check our your node editor work soon.

What exactly is the issue with nodes with infinite bounds? I have not tested myself. Rendering of gegl:checkerboard sounds like some that should just-work, so I'd be happy to accept patches if it does not.

I think the problem here is that a program like this:

#include int main (int argc, char **argv) {
gegl_init (&argc, &argv);
GeglNode *a = gegl_node_new (); gegl_node_set (a, "operation", "gegl:color", 0); gegl_node_process (a);
}

does not terminate. It creates a single color node and tries to gegl_node_process() it. But because the color node produces an infinite (virtual) image, the process node needs an infinitely long time to process it. Or at least this is the way i understand it. In its way, at least it is logical.

I think the problem here is not the process functionality, but the API; the function gegl_node_process() does not have an error return value, so it practically must not fail, and so it has to take the long path of processing for all eternity (or until it runs out of memory, whatever happens first).

It almost looks as if there needs to be som kind of bounding box to limit the processing to the part that might potentially be visible... Not sure how consistent that would be to the rest og gegl, though.

-- hendrik