NOTE: this improve some test by 10 to 15% some other are down by 5%.
Their is still more tunning and improvement possible now (Particularly
with Map), but it will do for now.
SVN revision: 73264
For no bidi: just don't set the bidi stuff. I.e paragraph props and the
other stuff (including text_props_direction_set). If you disable BiDi you most
likely want to disable shaping as well.
For no shaping: Disable bidi (i.e don't set direction) and pass
EVAS_TEXT_PROPS_MODE_NONE to info create.
This will prove especially useful for textgrid, but not only.
SVN revision: 72032
Now evas will in all case do the layout during the prepare stage. It will do that
once and as long as the text didn't change. This does improve by a factor of at
least 2.3 in all expedite test case except the text change that only get a 30%
increase (I expect a drop in performance on non pipe rendering for text change
expedite test only, but this case is not common in real life).
This also fix the issue that show random size glyph when using pipe rendering.
SVN revision: 71220
now seriously...
Introducing Cache Serve 2.
This cache server will initially load images for clients connected to
it. It starts slave processes to load these images, and share the loaded
images through shm with the clients. All the connection done between
clients and the server goes through sockets.
The cserve2 build option is turned on by default, while the old cserve
was disabled, but in order to make clients use it, the environment
variable EVAS_CSERVE2 must be set, and a server must be running.
Clients will try to find the socket on a specified location using the
environment variable EVAS_CSERVE2_SOCKET. If it's not defined, then the
XDG_RUNTIME_DIR path should be used, and finally HOME, TMPDIR and /tmp.
SVN revision: 70699
NOTE: This should be part of evas_render itself and not
delegated to the engine. So cleaning things to make it easier
during evas_render rewrite.
SVN revision: 70503
From: Thanatermesis <thanatermesis.ecvs@gmail.com>
Subject: [E-devel] LDFLAGS with -Wl,-z,defs
Aparently if you add the option "-Wl,-z,defs" to your LDFLAGS, there's some
libs that doesn't compile, like evas and e_dbus, there's some logs:
SVN revision: 68464
subject: [E-devel] [Patch] Add override gl apis for osmesa
When an application use glBindFramebuffer or glBindRenderbuffer via
evas_gl after loding libosmesa.so,it shows segment fault.
Because glBindFramebuffer and glBindRenderbuffer are not overrided.
So, I fixed it.
SVN revision: 68391
This optimization is significant for rendering to a large surface
because it'l save an extra copy overhead as well as an extra rendering pass.
To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface
config options_bits. The following conditions have to be met in order
for evas to render directly into the Evas' window. If they are not met, the
engine will fallback to rendering to an FBO as it normally does.
conditions:
1.) All the GL calls have to be called using the pixel_get_callback function.
This is necessary for the evas object order to be maintained.
2.) Alpha must be disabled on the image ojbect that renders evas_gl.
3.) No rotation allowed.
One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but
there is no guarantee in its behavior.
Currently, this optimization is added for gl_x11 engine only.
SVN revision: 67388
* This feature requires libOSMesa to be installed.
One caveat with OSMesa is that a surface config (ie. Depth Buffer and etc)
is associated with a context rather than a surface, which is the case
in EvasGL. So for now, when a user specifies a surface config, it gets
associated with the first context that the surface does a make current to.
For typical usage case, this shouldn't be a prolem. Will need to fix it
eventually.
SVN revision: 66896
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
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
Added Evas_Font_Instance and Evas_Font_Set which correspond to
RGBA_Font_Int and RGBA_Font. This is very important for strict type
checking which we now finally have.
This commit does not include logic changes, only casting and changing
types of pointers to the opaque pointer types.
SVN revision: 59782
More work, proudly supported by Samsung. Filters!
So now you can apply a whole host of cheesy visual effects to objects at
runtime. This is the first commit, there are a couple of more to come as I
tweak the filters, and fix blur with GL[1].
Please direct bugs to me nash@nash.id.au.
[1] You'd think shaders would be good at this.. but no, generic blur and GL
are like trying to get an apple product to work with Linux.
SVN revision: 58726
Now when setting :style=Oblique/Italic/Cursiva/Bold and etc and there's
no matching font found in the system, adjustments will be done on
runtime to support that feature.
Patch by Myoungwoon Roy Kim (roy_kim).
SVN revision: 58584
We have string objects, we don't really need them. Draw still uses strings
for metric cache, but that will be removed soon as well.
SVN revision: 58460
This seems to have got lost in my big messup before. This pushes enough of
mask/arbitrary clip to be somewhat useful. I need to push a little more soon
for it to be 100% happy, but this is useful level.
SVN revision: 58373
This lets us get the difference between the width and the advance
of a string pretty fast, which means we only need to calculate either
advance or width, because we can now calculate one from the other.
SVN revision: 58181