Subject: [E-devel] [Patch] Add scale down decoding feature to evas png loader
I add scale down decoding feature to evas png loader. 5515X3986 size png image need 80~90M memory,
but scale down(scale num=2) option can reduce memory to 25~30M.
I use down sample method for scale down.
(there is more efficient algorithm for scale down, I'll add this to my
todo list)
SVN revision: 64170
Subject: Re: [E-devel] [Patch] Implement scale down decoding feature of bmp loader
I implement scale down decoding feature of bmp loader using down sample algorithm.
Desktop have low risk to go wrong memory problem during big image decoding,
but mobile device is different.
Raster said it is life (meet memory problem during big image decoding),
and it is enough to return decoding fail.
But I think it seems a bit harsh, because 2 or 3 bmp image (5000X5000 size: for example)
can cause application close because of memory lack.
SVN revision: 64163
Subject: [E-devel] [Patch] modify gl engine's animated function
related with cache entry
I modified the gl engine code related with animated images
This is very trivial. Evas image object passes images to the engine.
In the software engine, it is a cache entry , but in the GL engine, it is
an Evas_GL Image. So I modified the gl engine code to get the cache entry
from the gl image.
SVN revision: 64143
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
Sorry mate, but they broke API without bumping version, that's why I
didn't do this myself. You should probably add your version of harfbuzz.
This reverts commit 64057.
SVN revision: 64134
You can't compile a gl_common .c file based on whether or not the SDL
header was included. The .c file will result in only one .o and since
the Evas_Engine_Sdl.h is not included by evas_gl_context.c itself, then
that ifdef will never be true.
gl_common should request a callback function pointer from the evas engine
for doing symbol resolution. This needs a refactor.
SVN revision: 64086
Rather than trying to avoid removing the list element that is
currently being processed, keep two lists and move elements
to the processed list before recalculating them.
Remove items from the list head only, and always append them
to the tail.
Use the fact that an item can be removed from a clist without
needing to know which list it is in.
Signed-off-by: Mike McCormack <mj.mccormack@samsung.com>
SVN revision: 64030
perfect" with 90 degree rotations. i really should have actually
special cased them, for for now i made the generic routine try and punt
out the right numbers.
SVN revision: 63986
ChunEon Park
Carsten Haitzler
Jiyoun Park
Cedric BAIL
Tom Hacohen
Sung W. Park
Mike Blumenkrantz
Youness Alaoui
Christopher Michael
Mike McCormack
Vincent Torri
Mike McCormack