This is really useful to track down a leak of a memory piece allocated by an
eet_data function. If you know the size of the leaked structure (valgrind
give you the total allocated size and the number of structure in it, so you
need to divide before having the right number), you just need to do :
EINA_LOG_LEVELS=eet:3 my_app 2>&1 | grep the_size
And there will be very few line matching reducing what you should be looking at.
We need the wayland-scanner program to auto-generate the
subsurface protocol source files from subsurface.xml
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
this makes curl support a pure runtime-only thing. libcurl is loaded by
eina_module (dlopen/dlsym) when curl is actually first needed (when a
url connection/object is created). this means that ecore-con has no
link or compile dependencies on curl, only runtime, AND this saves
memory (due to curl inits using apparently a chunk of private pages).
so this saves memory and moves the dependency to runtime (though still
consider libcurl a dependency of efl - but like a binary executed,
it's at runtime).
Wayland subsurfaces can be used as video surfaces too, similarly to
Ecore_X windows. However, they support a different set of features. Some
of them, like subsurface clipping and scaling, might be added in the
future, but so far we must work with what we have.
This commit allows to set an enum bitfield to the Video_Surface, with
the default value being one that will keep the same behavior as before,
for Ecore_X window. Thus, backward compatibility should not be broken.
It's possible to inform Evas that the surface in question is not able to
resize or scale, or that it's above or below the original canvas
surface. This allows Evas to show the surface itself, or use a buffer of
pixels instead, when the capabilities are not available.
If we are running on async render, some operations must be delayed, so
they will happen at the same time that the canvas rendering result gets
updated on the window/surface.
So current order is :
- __builtin_bswap*() for compiler that provide it
- _byteswap_*() for MSVC
- bswap_*() for older Linux and some BSD
- own C code when everything else fall appart.
The reason for this order is that the builtin will always generate
the best assembly possible. On my system bswap_*() are not changing
in all version to the best solution as they are almost equivalent to
the C macro.
I'm sorry, but those kind of commit messages are unacceptable for code
I'm the only maintainer of. It's bad enough that to have them in the
project in general, but this I won't accept.
I wanted to review this commit, but the lack of explanation about what
you are trying to fix and why you think this is the good fix prevents me
from doing my job. However, without really looking too much into it,
this commit looks wrong. evas_textblock_cursor_format_is_visible_get
should verify there's a format node...
Please come up with a better commit message and re-commit.
This reverts commit fe33aa7408.
This one fix size of the object that didn't take into account the style
of the text since we added the support of ellipsis in Evas. It also
correctly detect when we insert an ellipsis in the text to relayout
properly on resize.
We can't use ECORE_CON_LIBS at the examples/ "make" context
since it defines libraries relative to the src/ directory
(e.g. lib/ecore/libecore.la). Use ECORE_CON_COMMON_LDADD instead.
This fixes the following link error with ecore_fd_handler_gnutls_example
when the project is configured with --with-crypto=gnutls:
libtool: link: cannot find the library `lib/ecore/libecore.la'
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Only specify ecore_pipe_gstreamer_example in EXTRA_PROGRAMS inside the
HAVE_GSTREAMER makefile guard.
Fixes: https://phab.enlightenment.org/T423
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
This add finally support for JPEG 2000, but be aware that libopenjpeg
is very badly managed. There is currently only version 1.5.x that does
provide the right files, is usable by a third party and portable. You
can seriously forget any other version.
when using genlist and the edje item objects, there seem to be a lot
of excess textblock layouts happening. i was seeing about 12 layouts per tb
part in the edje before this patch. with this it's down to about 3.
Only the key is worth being a stringshare as it is used to do an efficient
binary comparison instead of iterating over all possibility. Also reused
some already known value and a few other speedup.
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
This reverts commit ee1b0833ed
I did it manually because the code changed too much.
We actually want this type, it makes things more clear and easier to
understand.
this is the first step on the road to remove class specific EAPI from Eo.h
using this handle we will know if a Eo* is a class or an object pointer
Conflicts:
src/lib/eo/eo.c
Note: Eina_Hash benchmark is not really matching all our usecase.
We need a better tests that would expand the bench with a wider range
of key size. Basically giving a 3d dimension to our gnuplot. Don't know
if it is doable.
This give an interesting +15% for all Eina_Hash user whatever hash function they use. The inlined
djb2 is still the fastest one and all other give very close result.
This idea was given by Lucas De Marchi's blog :
http://www.politreco.com/2013/09/optimizing-hash-table-with-kmod-as-testbed/
I do believe that rolling a crc32 implementation as a hash function should give interesting result
in our test.
This reverts commit b5fce696c7 and fixes
to NEWS and @since that came later.
These functions are pretty trivial and their functionality can be
obtained with asprintf() and snprintf. The first is not available only
on windows, but there's an implementation for that one on Evil, that
should be used instead.
objects that were visible and marked as "render del" rects during render are now detected when they magically change visibility during the same render loop, fixing a very hard to reproduce E19 corner case related to fullscreen client rendering with nocomp disabled
<raster> for now all i can say is "put the patch in and lets see if things break"
Although we kinda use them as max in some situations, they are actually
just the regular ascent and descent. Following commits will make this
separation even stronger.
Phab Ticket T359
https://phab.enlightenment.org/T359
NB: When setting the window opaque region, take into account any
existing window rotation, and set opaque region accordingly.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
body gets deleted here so better not access it afterwards. My guess is that
in many cases the actual free gets delayed long enough to not crash here but
better avoid this race in the first place.
CID: 1039896
NB: Needed so that we can reset the opaque region if alpha_set is
being toggled on/off all the time.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
NB: Master clip is needed so that things don't draw outside the client
area.
NB: This is a partial fix. Still a work in progress. Some remaining
issues with some various elm_tests that use evas_map.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The goal would be to replace the smart children list and friends. The
problem is that they differ in content. Smart children and Eo children are
the same, but Elm children and them differ. If I put this function as a
virtual, it would be possible to override the list of children and if we
start using it in Evas render loop, that could result in "weird" behavior.
I have added the use of a simplified Eina_Trash mempool kind of feature
to have some fast path for allocation if we start using it in Evas render
loop.
NB: We will still create all new canvases as alpha by setting it in evas,
however this allows the 'state' of ecore_evas_alpha_set/get to retain
it's original functionality and thus accurately report what a client
application May have set alpha value too.
NB: Fixes Phab Ticket T350
Signed-off-by: Chris Michael <cp.michael@samsung.com>
For EvasGL direct rendering, EvasGL does a make_current to the
surface that evas is holding on to. When EvasGL was shutting down
it was wrongly deleting evas' surface. This issue was temporarily
fixed by Raphael before but the proper fix was added.
It is quite common that in an image sets each image has different border size.
This patch permit to define the border value on a per image basis in the set.
I am really unhappy to have to do this patch myself. This commit is in since
May and I have continuously request to be fixed. It has taken way to long. It's
done now. Next time I see such a patch in EFL, I will revert it right away.
Remove calls to ecore_wl_window_update_size inside the alpha &
transparent_do functions (this call not needed here anymore).
NB: This is needed due to recent frame "fixes". Basically, even tho we
set the opaque region correctly on a surface now, if the canvas itself
is not alpha, then we will end up with a black "spacer" around the
window.
NNB: Tested Both engines with terminology (both translucent and not) and also the window state test in elementary.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
There was already a surface created by _evgl_tls_resource_create(). If
we assign a new one here, the wrong one will be destroyed at
_evgl_tls_resource_destroy(), and later the GL window will be destroyed
before the surface, causing invalid access errors.
This fixes https://phab.enlightenment.org/T326
Markup_get was misbehaving and returning wrong results with some escaped
chars. markup_to_utf8 was working correctly. Merged the code together
and now both are consistent and correct.
Thanks to WooHyun for reporting.
Tracking only the async rendering canvases and just waiting for the last one
to finish rendering. This should be enough to sync all canvases since the
render thread orderly executes the commands.
evas_render_sync() will loop through all canvases and wait for their
rendering to finish. Since this function will execute from the main
thread that will sync all of them.