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.