On Wed, Jun 3, 2009 at 8:45 PM, Giuseppe Rota <rota.giuseppe@xxxxxxxxx> wrote:
> I got stuck with the geglbuffer-add-image example, though.
> I expected to find, after a successful run, a file (first argument)
> containing the serialization (or dump, if you will) of a GeglBuffer (I
> used data/surfer.png as input).
> That did not happen so I inserted a gegl_buffer_flush(buffer);
> instruction before the 2 g_object_unref near the end of the main().
> That did the trick, I now have a binary file with the serialization of
> a GeglBuffer (first 4 bytes are "GEGL").
> This happens (on Linux) both with version 0.0.22 and with the HEAD svn
> version (both babl and gegl) (GIO enabled).
>
> Can you please explain the rationale behind this behaviour?
GeglBuffer currently lacks multi process support which it can (could?)
be enabled by patching GIO to allow simultanous read/write access from
different processes. With such extra tweaks I suspect that the example
would produce the desired output as written, this should be changed.
GeglBuffer was developed againt GIO it would have been better, and
will be better to mmap the file and share the tiles between processes
in that manner instead.
> On a unrelated note, what's the difference between gegl_buffer_load
> and gegl_buffer_open?
gegl_buffer_load loads a on disk buffer into RAM, swapping into the
users swap directory for tiles that are not stored in memory.
gegl_buffer_open opens an existing on disk GeglBuffer using the buffer
itself for swapping.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
