On Sat, Jun 7, 2008 at 9:34 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> I wrote:
>> Cedric wrote:
>>> I did some test around this and I think it came from the fact that
>>> o->dirty_pixels is not set to 1 after the second call to
>>> evas_object_image_size_set. A quick fix for your example is to call
>>> evas_object_image_pixels_dirty_set just after
>>> evas_object_image_size_set. I currently don't know enough to properly
>>> fix evas, but this could help others find the right solution.
>>
>> Well, the semantics of the image-size-set function has always
>> been that if there is no data or file for the image, it will create
>> data of the requested size, and if there is data (possibly from a
>> file), it will create new data of the requested size and copy as much
>> as possible of the current data to the new one and then set that new
>> one as the current data.
>> So, for the test program there, after the inital rendering
>> (of a blue area), when the resize is called the image would have
>> new data (not the provided pixels) one pixel less in width, so the
>> subsequent ecore induced rendering would still show the same result
>> (even though there's no further call to 'set data' as the callback
>> won't get triggered since 'dirty pixels' isn't called again, and
>> it's been unset after the first rendering).
>>
>> This would seem to show some new problem with the 'image-resize'
>> function when external data has been set before on the image.. and
>> indeed if I get rid of the pixels callback and simply set the data
>> (after the initial image size setting), then the problem is still
>> there even without the first call to evas render.. ie. the second
>> call to image-size-set seems to be the culprit.
>
> Took a quick look at the software_generic engine, and in the file
> evas_engine.c, we see the following implementations of say:
>
> static void *
> eng_image_size_set(void *data, void *image, int w, int h)
> {
> RGBA_Image *im;
>
> im = image;
> return evas_cache_image_size_set(image, w, h);
> }
>
> static void *
> eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
> {
> RGBA_Image* im = image;
>
> if (!image) return NULL;
> im = (RGBA_Image *) evas_cache_image_dirty(&im->cache_entry, x, y, w, h);
> return im;
> }
>
> We may contrast these with the signatures of the called 'cache'
> functions, in the evas_cache_image.c file:
>
> EAPI Image_Entry *
> evas_cache_image_size_set(Image_Entry *im, int w, int h);
>
> EAPI Image_Entry *EAPI Image_Entry *
> evas_cache_image_dirty(Image_Entry *im, int x, int y, int w, int h)
>
>
> So, it may be that something's not quite correctly called here.
> It's also possible that the actual implementation of the function
> "evas_cache_image_size_set" isn't doing 'the right thing', but haven't
> had a chance to look... Cedric?
No this is correct. But eng_image_dirty_region is not called in the
second case. If I force the dirty_pixel to 1, it call
eng_image_dirty_region and every thing goes ok. So perhaps in case we
have func.get_pixels set, we should on resize set dirty_pixel to 1. I
think this should sove the issue, but I am not sure it's really the
correct fix.
--
Cedric BAIL
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
