don't try to do these on the framespace clip object. Also, since we
need the evas to get the framespace clip object, just directly use the
framespace values from the canvas, rather than function call to get
those values.
SVN revision: 75989
Subject: [E-devel] [PATCH][RESEND][Evas] WebP image loader
This patch adds a WebP image loader to Evas. No saver,
no animation support for now, just loader. Tested with
the libwebp-0.2.0 only, but should work fine with older
versions.
SVN revision: 75951
Subject: [E-devel] [patch] A function to rotate an evas map with a
quaternion
So this is a patch to rotate an evas map with a quaternion.
You can use this to avoid gimbal lock... for example in the elementary
evas map 3d test, if you put the Rot y angle to 90 then Rot x and Rot
z will do the same rotation...
SVN revision: 75920
Direct Images. Add support for using native image binding. Add support
for setting GL surface capabilities. Fix up some overrides to be in
the proper place (glsym vs evgl).
NB: Yes, it is a bit large of a change during freeze, but there are no
API changes here, and it is well tested. Nothing broken (beyond what
was already broken).
SVN revision: 75826
Lets wait until after the code freeze is over and people apply their
patches, otherwise it'll be hellish.
This reverts commit 75632
SVN revision: 75704
The map cache must be dropped if the content of the surface is rendered again.
The example evas-smart-object.c has a valid test case for this bug.
SVN revision: 75636
Rotating the smart object with map, adding a rectangle as child, and then
rotating it again will expose a bug on mapped smart objects: it's mapped
surface will be reused from cache, instead of flagged as dirty and discarded.
SVN revision: 75635
Fixed bug with 1 char word separators at the start of the
text when going to the start of the word (e.g: =test).
Reported by Thiep Ha. Thanks a lot.
SVN revision: 75595
function, we should do the same for events. This fixes the cursor
position in elm widgets.
NB: I have been running this patch for 2 days and see not bad side
effects in either wayland engines, or X11 engines. Patch from Robert
Bradford @ Intel, slightly modified by myself to avoid the overhead of
another function call.
SVN revision: 75309
adjust the clip size and position if something changed.
NB: Found this during final fullscreen testing where, when fullscreen,
the clip was not getting moved or resized.
SVN revision: 75291
When we create the egl window we should take rotation into
consideration, so account for that. Add an 'edges' variable to the
engine info structure. This is needed so we can implement resizing
windows from the top also. Make sure to use
wl_egl_window_get_attached_size and determine the edge we are resizing
from, so we can calculate the difference in sizes to send to
wl_egl_window_resize.
Add __UNUSED__ to function paramaters where it was missing, and fix
some compiler warnings.
SVN revision: 75215
now here's the rub. from the glibc manual page:
...
int memcmp(const void *s1, const void *s2, size_t n);
DESCRIPTION
The memcmp() function compares the first n bytes (each interpreted as
unsigned char) of the memory areas s1 and s2. It returns an integer
less than, equal to, or greater than zero if s1 is found, respectively,
to be less than, to match, or be greater than s2.
RETURN VALUE
The memcmp() function returns an integer less than, equal to, or
greater than zero if the first n bytes of s1 is found, respectively, to
be less than, to match, or be greater than the first n bytes of s2.
...
this explicitly says that s1 and s2 have their BYTES compared... and
then returns just some value < 0, 0 or > 0 based on the difference. what
that value is and means is not defined, as long as it is < 0, 0 or > 0.
so the C standard has this to say:
6.3.1.3 Signed and unsigned integers
2. Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.
so a result of -255 (possible) is converted by REPEATEDLY adding the
max size of the new type (255) until within range... so ...
-255 + 255 = 0 ... within range.. BUT FALSE!
so why do we see this now? something changed in memcpy behavior.
before we ONLY saw values of -1, 0 or 1 - nothing else, NOW we see
thins like:
-12288
49152
4096
16384
61440
-53248
so memcpy changed behavior, though within specs of the manual page
anyway, but now the values can be ones that break the simple assignment.
SVN revision: 75159
window at this point, so we cannot use it for comparison. Instead,
check the requested depth. Also fix best_depth_get function to not
return a hard-coded depth if a depth has been set already.
SVN revision: 75082
was using evas' window surface to do its resource creation and it
wans't properly updated when a window is destroyed and recreated.
Also, deleted some whitespaces.
SVN revision: 74771
position. Fix bug when clipping to viewport/framespace. These changes
fix Several buggers on Trac which related to the Wayland Engine(s).
Fix minor bug in evas_render where clipping for framespace would
not take into account the frame height and also move the frame clip to
the values specified in framespace (not viewport).
Fix buggers in evas_object_main which was causing objects (when created using
the wayland engines) to be an incorrect size & position (objects will now
be the same size/position in EFL Wayland as they are in X11).
Fix evas_object_geometry_get to return values based on where they were
moved (in relation to framespace). (These fixes are for the Wayland
Engines and do not affect X11).
Remove nw/nh from evas_object_resize (not needed variables anymore).
SVN revision: 74565
Used to just go for the first match in the cache which means it would always
think we only have the wrong size in the cache, and it would just add
new entries all the time.
SVN revision: 74435
Subject: [E-devel] [PATCH]Evas.h comments patch
When reading the comments of 'evas_object_textgrid_update_add' I
noticed
a little cnp err. The enclosed patch is just a suggestion, but the
misleading comment was driving me nuts...
SVN revision: 74331
wayland_egl engine caused by windows being hidden:
From: Rob Bradford <rob@linux.intel.com>
Date: Fri, 13 Jul 2012 19:13:12 +0100
Subject: [PATCH] evas(wayland_egl): Resolve a series of segfaults on
clean-up
The first was that when a window was being hidden the render engine
(e->engine.data.output) was being assigned to NULL (like on an error
path). I
checked other backends and they only free and nullify this pointer on
error
paths. By doing it on a hide it was interfering with cleanup process
for the
object.
This then highlighted a second crash from the derefence of the window
to NULL
when flushing the cache. If the window was hidden this window pointer
would
be NULL.
The third it highlighted was a duplicate call into
evas_gl_common_image_free
and the freeing of the image cache twice. By the time eng_image_free
has been
called the cache has already been freed so we can remove the duplicate
free.
SVN revision: 74330
From: Alex Wu <zhiwen.wu@linux.intel.com>
When calling elm_win_alpha_set(), the global EGLContext object keep
unchanged, but the new EGLSurface object subjects to the new EGLConfig
with changed alpha_size. This makes eng_window_new() failed and hence
free the Render_Engine object (e->engine.data.output) and nullize it.
Next time other objects reference the output, segfault occurs.
In this patch, I give every Evas_GL_Wl_Window object a EGLContext object
and all these EGLContext objects share the same shader program objects.
A new global EGLContext object "share_context" added, which is
responsible for keeping the shared objects alive. e.g. shader program
objects.At the first time succeeded to create a EGLContext, assign it to
the "share_context", and should not destory it in eng_window_free.
The "share_context" will be taken as the 3rd argument when calling
eglCreateContext(), and then updated to the new created EGLContext to
keep the shared gl objects available.
Thanks for devilhorns' review and suggestion.
SVN revision: 74328
The arguments for image_map_draw changed, and these engines were receiving
the wrong data. In the case of gl_cocoa and gl_sdl, the gl_common would
receive a pointer for 'npoints' and would call abort() because npoints
is not 4.
SVN revision: 74321
NOTE: That one is nasty and I do admit that this doesn't
sounds like the proper fix, but as it doesn't trigger other
issue and is simple/reasonable I took to defeat that damn
beast.
SVN revision: 74180
evas_object_image_file_set tries to load the file even if the file is NULL,
this in turn makes proxies always report about an error, although there
isn't really one.
I'm not sure whether evas_object_image_file_set should behave the way it
does, but I'm sure the proxy needs to reset the error anyway (because of
potential previous errors).
SVN revision: 74073
The flag and pixel data will be set on this callback, avoiding new
image_load_data() to create a new request or wait for the LOADED
message.
SVN revision: 73999
A lot going on here:
- Request callbacks were adapted to fit the new scheme
- The old requests systems in the cache was wiped out
- Old slave handling in evas_cserve2_main.c is dead too
- PRELOAD commands are responded with LOADED now
SVN revision: 73984
Message creation was like that already, but now we call the response or
error callback for the request only once. The cache does what it needs
there and returns, in the case of a successful response, the message
that will be sent to the client.
SVN revision: 73981
We don't use this cache with cserve2, so it makes no sense to keep async
preload disabled. When not using the cserve2, even if built with that
option, it will support preload with no side effects.
SVN revision: 73422
loading glyphs.
Instead of measuring the time spent by the server between asking and
receiving the glyphs rendered, we measure now the time spent by the
slave to load the glyph, and then to render it, and then we report this
time to the server.
SVN revision: 73373
The only two available versions of doxygen for e2(debian sid), where
online docs are generated, are borked. The newest version(1.8.1.1) is
extremely borked so best to just use the old one(1.7.1.1-2) which
doesn't properly parse EXAMPLE_PATTERNS.
SVN revision: 73358
This gives Evas simple (smart object) interfaces, to extend the object behaviorextension beyond the limits of mere sub-classing.
Patch by: Gustavo Lima Chaves <glima@profusion.mobi>
SVN revision: 73302
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
NB: This is the commit message inside tizen git for this commit. Don't
blame me if the message is not detailed enough for you. Complain to
the original committer about making more detailed commit messages.
SVN revision: 73213
1. We already check in configure.ac that harfbuzz is at least 0.9.0, so
those code paths will never get triggered anyway.
2. We don't plan on supporting old harfbuzz anyway. People should just
upgrade harfbuzz (Not really an issue since it's not yet released).
SVN revision: 73197
- Added (w,h) <=0 dimension check for evas_gl_surface_create()
- Changed evas_gl_make_current to return error when either
surface or context is NULL. Semantically, this was allowed
before but it was changed to reflect eglMakeCurrent behavior.
- evas_gl_make_current - detached any previously attached
buffers before attaching new ones to an FBO during a make_current.
- Used dynamic memory for extension string allocation for safety.
SVN revision: 72926
to cserve2.
Big commit that implements the entire functionality. Besides loading
fonts and glyphs, and sharing the glyph bitmaps with clients, it also
adds:
- new request system, with a much better abstraction;
- new working slaves management;
- slaves can be threads or process now;
- started a debugging and statistics implementation on server.
The image caching part still uses the old request and slaves system, but
should be changed to use the new one soon and get more easily
maintainable.
SVN revision: 72699
This patch reuse the same Evas_Text_Props across the textgrid (Later we could do that
across the canvas itself, but no test case yet, so not yet). It delay the real destruction
of Evas_Text_Props after the rendering cycle, so they will really die only if they are
not used during the latest frame. We could delay it a little bit more, but that does
the job at the moment.
SVN revision: 72510
Nowadays, this engine is completely useless. Windows users (>= XP) use
only 32 bits depth color, so let's kill that engine. Less code to
maintain for me.
SVN revision: 72494