The "pixels" pointer was set in the beginning of evas_object_image_render(),
and never updated, even after pixels_get() changed the content of
o->engine_data.
This patch updates that pointer if it becomes different from engine_data.
SVN revision: 63090
Subject: [E-devel] [Patch] evas gl engine's texture creation
Hello.
1. _pool_tex_dynamic_new function, it didnt set pt to NULL when secsym_eglCreateImage function failed.
In this case, it returns wrong pt pointer and it has possibility to make crash.
So I add free pt code and return NULL code into _pool_tex_dynamic_new function.
2. I modified eng_image_data_get of gl engine.
If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped,
Im->im can be NULL. So I add check code.
Example: evas_gl_common_image_content_hint_set
1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image
2) if evas_gl_common_texture_dynamic_new failed
3) then, im->im =NULL, im->tex=NULL
In this situation, if application call's evas_object_image_data_get function,
It make crash in evas_cache_image_load_data function.
3. I think function's related with evas_object's engine data have to be return NULL if it failed.
If function's returns null, evas object code can handle error more easily.
But evas object's code was implemented differently each case. Does my suggestion right?
I add engine data null check code to evas_object_image based on upper consumtion.
If it is wrong , the patch code related with evas object image have to be removed.
If it is right , I will survey other evas object type also.
SVN revision: 62775
Subject: RE: [E-devel] [Patch] Animation gif feature patch
Animated gif suport in evas and api's to handle animated images and
frame flipping. from jy.
SVN revision: 62331
Although the uv range of normal object is be localized to the it's geometry,
but the uv range of the image object is be localized it's image size but not geometry size.
In that case, user should find out the objects type and set the uv value differently between normal and image
why they do that?
SVN revision: 61577
thats not released yet) wher using proxy via map doesnt let you use uv
coords right as its ALWAYs filling/scaling only due to not using
source image size and proxy size right.
SVN revision: 59519
as there was no cleanup.. and the method of exposing
evas_filter_key_get() was so out of step with any other code i have
ever seen.. letalong evas... fix.
SVN revision: 58747
Cedric BAIL
Mike Blumenkrantz
Carsten Haitzler
Rafael Antognolli
Jiyoun Park
Daniel Juyung Seo
ChunEon Park
Christopher Michael
Brett Nash