Summary:
When input string has non-finished markup tags or escaped tags,
eina_strbuf_append_length is called with Null string.
There is a Null checking in eina_strbuf_* API, but it will print error message when input string is Null.
Strictly speaking, *_markup_to_utf8 API could be used with any kind of input string.
So, we need to add Null checking for removing the useless error message.
Test Plan:
Call the API like the following code.
evas_textblock_text_markup_to_utf8(NULL, "test_text&&&&");
ERR message will be printed.
Reviewers: woohyun, tasn, seoz, Hermet, hbr4570
CC: cedric
Differential Revision: https://phab.enlightenment.org/D493
This is a long awaited feature that has been requested years ago.
Fontconfig finally added the support needed to make it happen, so here
it is.
I added a fontconfig query to look for similar fonts in case we loaded a
font from eet/edje/file(no fontconfig). This now works quite well.
Still missing: if you load a bold/italic/whatever font directly (set the file)
without putting ":weight=bold" you will not get run-time emboldenment if
only non-bold fonts are found.
This unfortunately depends on very recent fontconfig version (#ifed out
when unavailable), so only people with fontconfig >= 2.11 will enjoy
this feature.
This doesn't work nicely, as for some reason fontconfig doesn't work
nicely with ':spacing=mono' without a font name.
Doesn't work with fc-match either. It does work with fc-list, but that's
not what we'd like to use. It could be just an issue with my local
fontconfig configuration.
This fixes T865 although the problem is now with freetype.
This is a regression introduced in
548e548632.
This is really bad, and essentially broke selection geometry for bidi
text. Very serious.
The problematic code assumed that the range comparison for the items
assumed the item marked with 1 is always logically before the item marked
with 2, which is just not true.
So I have a weird crash in terminology.
Reproduction path:
eet -x /path/to/elm/theme/default.edj edje/images/537
Scroll back in the terminal buffer, to show the entire file: CRASH.
Reviewers: cedric, tasn
CC: cedric, raster
Differential Revision: https://phab.enlightenment.org/D468
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
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... :(
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!?
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
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)
If a file had changed, a new OPEN message was sent, and the
client image ID was then changed, but the LOAD message was
sent with the previous image ID. So cserve2 would not be
able to honor that request.
When an image file is changed, it is discarded from cserve2,
so the references become invalid. In case we were loading a
scaled version of that image, no proper error checking was
done, leading to obvious crashes.
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
In cserve2, a shortcut was taken to check if two images were the
same, using memcmp() on the Evas_Image_Load_Opts struct. But it
seems some empty areas in the struct are uninitialized, potentially
making memcmp() fail when the images were actually the same.
This is a minor issue since this function is called only when
bypassing the socket wait.
Also, memset load_opts to 0 and copy all the fields to avoid
the same warning in socket send().
I'm just wondering about the performance impact vs. memcpy/memcmp.
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
- Invalid alloc size (typo)
- Initialized value never read (set twice)
- Potential memleak (call free(msg) in case of send error)
- Null pointer dereference (check nullity)
There are still other warnings, but I believe these are false
positives.
since the map_changed is reset right after the map is updated,
it could not decide to redraw the map surface properly.
now map_update() returns the value to redraw the map surface properly.
We do have mmap provided by Evil, but there is no implementation yet of
an anonymous map support. Also it is not clear how the memory system of
windows does actually work, so not sure this optimization is relevant
to windows at all. Thus we disable it for the time being and unbreak
the windows support.
- cherry-pick me -