> > And let me throw in another thing. It's been in my head for some
> > time but now I think it's good to show it to the world. Just in the
> > matter of shear curiosity: I'd like to see some conceptual
> > work/code/working example/whatever about automatically configurable
> > grid processing. It may be more of GEGL project than GIMP one, but
> > I believe still beneficial in the end. Since 3D rendering engines
> > do that, maybe it would work nice in 2D world too. Of course a
> > metric and some kind of benchmark would be needed to decide if
> > sending some part of work over network to another node is
> > beneficial. Anyway I think it have chances to make things snappy
> > even on slow machines. I see it as a something between freakin' fat
> > workstations, thin clients with some heavy “mother goose” and
> > mighty cluster. It would (hopefully ;)) help to use what is at hand
> > more optimally.
> 
> GEGL is designed to be able to split up the rendering requests from
> the public part of it's API internally and to distribute it among
> threads/processes/hosts without needing changes to the application
> using GEGL. At the moment there is only experimental support for using
> threads in this fashion, but the architecture has been made with
> distributed processing in mind. This also applies to the GeglBuffers
> for which there a few years ago already was done experiments with
> doing multi process/user concurrent manipulation of the same buffers.

All of which makes a great opportunity to go from “some experiments” to
“actual application” :). Agreed such project would fit GEGL better but
some GUI to control GEGL behaviour in that matter would be required
nevertheless. Besides… design with delegating processing to multiple
threads in mind is one thing and “making it just work” over net is
another. That's why I think some (at least conceptual) work is needed
to make such thing automatically configurable (avahi shouting
about such service available maybe, some metric to decide if letting
a node to take part of work is beneficial).

Best regards!
thebodzio

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to