An invalid optimization was implemented in proxy rendering.
We can't assume a proxy is a smart object.
Refer to 5cefa00d0a.
Fixes T832.
Proxy rendering is still broken when using cserve2... :(
apparently I read the commit order wrong and this fix went in for 1.4.0, not 1.3.2, which means anyone who has 1.3.2 has been having lots of fun crashes for the past 24 hours
This function does the following operation:
COPY pixel x mask --> dst
But it wasn't iterating over the source. So it was repeating
the value of the first pixel over and over again.
Is this even used anywhere? RGBA + alpha mask function!?
this was a fixme which was likely written sometime before July 2010 when the bug was fixed, just prior to the 1.3.1 release. I think it's probably okay to require that release since it's been 3+ years.
This reverts commit f8b0322704.
this breaks efreets icon cache. i have been noticing this since
yesterday across all my machines once i update just efl. i tracked it
down to this commit.
Summary:
When processing random data result of this function differs from C variant in more than 50% cases.
This difference is due to alpha calculation, in C code :
a = 256 - (c >> 24)
in NEON:
"vmvn.u8 q7,q6 \n\t"
// ie (8 bit)~(c>>24) === 255 - (c>>24)
We cant just add "1" as overflow will occur in case (c>>24) == 0 (we use only 8 bit per channel in vector registers)
So here is the solution:
copy *d right before multiplication and add it to the result of it later.
This makes the function slower by 20-30% but it is still at least 2 times faster then C code.
Reviewers: raster
Differential Revision: https://phab.enlightenment.org/D455
The code was giving enough memory to store doubles and longs, but they
could be unaligned as "unsigned char" allows 1-byte alignment, while
double may require 8 bytes.
By specifying the array as "long long" we force certain alignment in a
platform independent way. As this array is small enough and
short-lived, the number of items were not changed, this results in
more bytes on the stack but it shouldn't matter.
When over-allocating (past "pool->max" items) a memory slice will be
allocated to the new item as a linked list using Eina_Inlist.
The original code was placing the Eina_Inlist structure (3 pointers)
at the beginning of the allocated memory. However the item must have
proper alignment based on "pool->item_size", otherwise a structure may
end with unaligned members. Take for example MIPS 32 bits, it uses 4
bytes pointers with 8 bytes double. A structure containing a double
could have it unaligned as 12 % 8 = 4 (12 is the size of Eina_Inlist,
that contains 3 pointers), and MIPS doesn't allow unaligned access.
Albin Tonnerre (Lutin) spotted this in his Debian MIPS test machine,
it was breaking at eet_data_get_double() that was storing an unaligned
double. This was being called from within edje test suite.
The current code will place the list node after the requested
"pool->item_size", of course guaranteeing the pointer inside the node
is aligned (otherwise a "char" or "short" would break its alignment).
Summary:
When user paste text to elm_entry, _edje_entry_user_insert is called.
We need to reset a prediction buffer just like _edje_entry_text_markup_insert.
Reviewers: seoz, Hermet, woohyun, tasn, jihoon, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D461
I do think that it was a left over from previous file format. Removing
this memcpy should make Enlightenment startup faster and should reduce
by 500KB the memory it use.
It is sometime useful to start from a defined buffer, but to not touch it
until needed. This make life of caller more easier as they don't need to
duplicate the buffer themself as Eina will now take care of that.
Summary:
"_edje_entry_imf_event_delete_surrounding_cb" changes text of entry.
When the callback function is called and the entry is changed,
we need to notice to applications that the entry is changed.
Reviewers: seoz, Hermet, tasn, woohyun, jihoon, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D460
In the previous commit, style padding has been changed, so
that lines don't get extra space just because there's a special
style (glow, ...)
This adds some test cases that check the actual geometry of the
lines relatively to each other.
NOTE: This test does not fail before the padding commits, as
_relayout_if_needed() adjusts the padding properly.
Summary:
If ONE single item in the whole textblock has a padding of k,
then ALL the lines of the textblock will be padded by k pixels.
Here's a solution to add the padding only to the first line.
Test Plan:
Write any multiline text, without styles, in an entry.
Add some glow to one element. All lines should be spaced by
an extra 2 pixels.
Reviewers: tasn
CC: cedric
Differential Revision: https://phab.enlightenment.org/D442
Track padding per paragraph, since this is how it is computed.
Problem before this patch:
- If markup text is changed, padding may grow, and the layout is updated (good)
- If the UI itself needs a relayout, the old padding value is NOT reused,
so style paddings will reset the padding to 0.
Test protocol:
- Set some text with style=glow. The whole object should have padding 2,2,2,2
- Relayout the UI, the whole object will have padding 0,0,0,0 (should be 2,2,2,2)
Jihoon Kim
Carsten Haitzler
Jean-Philippe Andre
Cedric BAIL
Mike Blumenkrantz
Tom Hacohen
Gustavo Sverzut Barbieri
Daniel Kolesa
Jaehyun Cho
Youngbok Shin
Jean Guyomarc'h
Jérémy Zurcher
Chris Michael
ChunEon Park
Sebastian Dröge
WooHyun Jung
Guillaume Friloux
Daniel Juyung Seo