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
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
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
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