Georg Holzmann wrote:
Hallo gem devs!
thanks for the files:
I need some fast changing images and so I added a open-message to pix_buffer_write, so that I can load an image into the buffer. I read the image like this:
imageStruct *image = NULL; canvas_makefilename(getCanvas(), filename->s_name, buf, MAXPDSTRING); image = image2mem(buf);
so my question is: do I need all the cache-stuff like in pix_image, or is a simple image2mem sufficient (like above) ?
no you don't necessarily need the cache.
however, i reject your patch, since i don't think that [pix_buffer_write] is the apropriate place for this operation. instead of have moved the open()-functionality into [pix_buffer] itself.
(i consider the pix_buffer-objects very much like the table-objects within pd: you don't tell [tabwrite] to load a file into a table, rather you send the request directly to the table (or use a specialized object))
Now for the next: pix_buffer_read I just noticed, that pix_buffer_read needs much more cpu than pix_image, because stuff like this:
Obj_header*ohead=(Obj_header*)pd_findbyclass(m_bindname, pix_buffer_class); [...] pix_buffer *buffer=(pix_buffer *)(ohead)->data; [..] img=buffer->getMess((int)m_frame); if (img && img->data) img->copy2ImageStruct(&state->image->image);
is called every frame!
the problem with your solution is, that it crashes as soon, as you delete the associated [pix_buffer] object.
to fix this, you _have_ to do a pd_findbyclass() each and everytime you access the data behind it.
i have done so and you can find both your improvements in the CVS-head.
mfga.ds.r IOhannes