I am getting a segfault when calling evas_object_image_data_set() using the directfb engine. Looking at the source for the engine, I can see what the problem is, but I'm not entirely sure how to fix it.
The problem is that evas_engine_directfb_image_new_from_copied_data() frees the image_data buffer passed to it. The expectation, it seems, is that the buffer is to be gotten from evas_engine_directfb_image_data_get(). But, as in my case, if the buffer is created by the application (outside of evas), it's not correct for evas to free it. Judging by the FIXME comment just above the call to free, I'm willing to bet whoever wrote this code knew that too. The best solution would be for dfb to be able to support external buffers. Judging by the fact that evas_engine_directfb_image_new_from_data() simply calls evas_engine_directfb_image_new_from_copied_data(), I'm guessing that this isn't supported by dfb. A sensible workaround to this problem would be for the engine to remember the pointer created in data_get() for that image. Subsequent calls to data_get() will reuse that pointer if the image size is the same as the last call. If the image size is different, data_get will free the old buffer and allocate a new one. Then, when the engine shuts down, evas_engine_directfb_output_free will free any memory that's been allocated from data_get(). Perhaps someone could suggest a better solution? Also, in general, how well maintained are the non-software_x11 engines? It seems to me that all the other engines (except for the buffer engine, perhaps) are really second class citizens. The GL engine has now reached the point where it's being disabled by default. Will it eventually be removed? Will the other engines also accumulate bitrot and gradually become disabled and eventually removed? I'd appreciate knowing, because I don't want to waste my own time building a solution on unmaintained code. Thanks, Jason.
signature.asc
Description: This is a digitally signed message part
