Subject: [E-devel] [Patch] Evas gl shader use binary shader
I make patch related with evas gl binary shader.
The concept of binary shader is compile shader only once.
Some people want to use binary shader because of performance issue.
In current evas gl engine, every application have to compile shader each
time.
But I modify code , so only first running application need compile shader.
Other application use already compiled shader(binary shader)
The binary shader is made under HOME/.evas/gl_common_shaders directory.
Binary shader is created according to GL vendor,GL renderer, GL version and
Module_arch.
The basic flow is
1. First running application which use gl engine check binary shader
directory, but it can't find binary shader.
2. After compiling shader, It saves compiled shaders..
3. Other application checks shader directory, it can use binary
shaders.
In mobile target, using binary shader, I can save 150ms. (that time, there
is 11 shaders).
If there is more shaders and more applications, this flow maybe save more
total time.
(the above is now in, changelog coming, with change to using ~/.cache,
some formatting fixes, make ity do the desktop gl one right with the
retrievable hint parameter ont he program etc. - doesn't break desktop
gl at least. yay. a,so fixes to mke it compile at all).
SVN revision: 59167
Thanks to Brian Wang for the report.
This happened because we were querying for the index of the wrong fi,
this became especially visible after we started caching fi.
SVN revision: 59152
Only call eina_threads_shutdown when thread are dead and not before.
Release and destroy thread lock before calling evas_async_events_process
as you should never have a lock taken in the main loop when calling it.
SVN revision: 59119
Subject: evas_gl_api_get patch.
Here's a patch that simply overrides the GL functions for Evas_GL
except for two functions that I provide on my own. It may have some symbol
resolving warnings but that'll all go away eventually when we do everything
via dlsym or getProcAddress.
You can apply the patch to the latest revision of evas. (I've just
updated them) I'm also attaching a sample GLES program that uses
evas_gl_api_get. You don't need to link it to -lGL.
SVN revision: 59092
This lets you toggle the password mode inside the text. Especially
useful for implementing "show last char" in password entries.
Patch by Shilpaonkar Singh
SVN revision: 59000
Harfbuzz needs unicode querying functions in order to work properly,
until there'll be a nice lib that does that (should be under dev) we have
to depend on an outside source. This commit uses new Harfbuzz API that
lets us not care about the unicode function provider and just let harfbuzz
to manage it on it's own.
SVN revision: 58961
This lets us only relayout what's needed also when inserting formats.
This means inserting <b> </> for example is now as fast as inserting any
other char and doesn't cause a complete relayout.
SVN revision: 58958
Soon I will also do it for all cases, but it's not possible at the
moment because we depend on harfbuzz for querying unicode properties.
SVN revision: 58924
more. making a loader is a matter of a binary of a specific name and
evas passes certain input on the cmd-line and your binary produces
output on stdout (and also optionally additionally in a shm or tmp
file).
SVN revision: 58914
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
Patch from Thierry el Borgi with some rework of myself.
NOTE: I don't have much file to test, so if some don't
contact us with those file and we will fix the loader
if needed.
SVN revision: 58873
This fix is just until we finally split to scripts and cache fi all
the time, i.e in all the possible paths (regular, fribidi and harfbuzz).
SVN revision: 58806
(part of the evas-gl work)
the patch basically checks to see if the current context is evas' gl context
and if it is, it'll call evas_gl_common_context_flush(). I think this
is the proper
SVN revision: 58786
Kerning: We are walking the string visually so we don't need to do
anything special for kerning when in rtl, freetype works with "left" and
"right" which we automatically get.
Rendering bug: Cedric found that in some cases there were missing
characters. This was caused because I forgot to convert the kerning from
16.6 fixed point to int.
SVN revision: 58783
etc. etc. in corner-cases. it also re-factors the image cache code to
be much more manageable and understandable with cache/list management
doing the right thing in the internal calls.
SVN revision: 58779