Re: [Gegl-developer] geglbuffer-add-image writes GeglBuffer to disk only after a gegl_buffer_flush()?
Hi, I was busy these days with some other personal things, I have read some of the code on GEGL Buffer and the documentations, and i think I can startup the multiprocessor support patch. I just wanted if anyone can just find some time to explain me that how should I proceed and what would be the final objective i should keep in mind. Also It would be very great if Jerson can just tell me that how is he proceeding up with the problem and what solution has he formed in mind. I am not much clear about how should i proceed. Thanks, Utkarsh Shukla ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] geglbuffer-add-image writes GeglBuffer to disk only after a gegl_buffer_flush()?
Hi Utkarsh, I'm not an expert, but here's my take on this. You should probably start by examining GeglBufferIterators (gegl/gegl/buffer/gegl-buffer-iterator.c) and how they are used by GeglProcessors (gegl/gegl/process/processor.c). While you're at it, it would also help if you can study all graph-related constructs (gegl/gegl/graph/), especially the parts on GeglVisitors (gegl/gegl/graph/gegl-visitor.c) and GeglVisitables (gegl/gegl/graph/gegl-visitable.c) and their descendants (i.e. GeglNodes and GeglPads). I suspect that these are the parts where the bulk of multi-threading should be implemented. As to your project's relation to my work, I'm currently looking into OpenGL thread-safety. One solution that I found is to create a hidden OpenGL context after initialization and create one shared OpenGL context per thread. The other (much more attractive) solution is to do all OpenGL operations in a single rendering thread. Threads that require OpenGL operations will 'enqueue' their operations on the rendering thread. The latter solution is better, imho, because context switching is both costly and complex. Regards, Daerd ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] geglbuffer-add-image writes GeglBuffer to disk only after a gegl_buffer_flush()?
By the way, it would be awesome if we could see you in #gegl. We can discuss things there in real-time. Regards, Daerd ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] geglbuffer-add-image writes GeglBuffer to disk only after a gegl_buffer_flush()?
On Wed, Jun 3, 2009 at 8:45 PM, Giuseppe Rota rota.giuse...@gmail.com 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
