this api makes it far more obvious as to how to verify an eet file via
the eet identify mechanisms that use x509 certificates to sign files.
this is consistent with the api used to generate the key for sigining
thus you can use the same certificate file to compare against for
identify.
@feature
Commit 101dee79b0 introduced critical errors, as standard
error callbacks now fail.
Apparently, these error callbacks depend on the installed version
of libjpeg (8 vs. 9).
I couldn't start E without this commit.
even if not necessary in this particular case,
do as in eet_mmap() and eet_open(),
lock the cache before altering Eet_File struct.
fix CID 1039366 1039367 1039368 1039369
While we are likely will keep the embedded copy for a while to avoid a really
new dependency we allow now to use the external liblz4. You need at least
revision r120 and a package that ships the pc file for it.
Personally I would like to get rid of it rather sooner than later due to the
security implications and a bunch of code we ship but have no idea about.
Reality is that it will need some time until this new lib is actually
packaged and shipped with releases for a a majority of people.
This patch was co-worked with Doug Newgard <scimmia22@outlook.com>
The TGV file format and GL engine now support ETC1 encoding
with alpha using an extra texture.
This commit adds similar support to the Eet encoder/decoder.
@feature
Due to some invalid geometry considerations, there was a
1 pixel distortion in images, varying with the lz4 compressed
macro-block size.
Anyhow, I couldn't wrap my head around Cedric's code. So I rewrote
the whole thing instead, fixed it and improved the block size
selection (based on the image size, to optimize lz4 compression).
There were a few critical issues:
- Invalid pointer arithmetics on the input data (char vs. int)
- Invalid logic in the pixel duplication code
All of these due to bad copy and paste :(
Also, use LZ4HC instead of LZ4 when compression is enabled.
ETC1 encoding is so damn slow you won't see the difference between
LZ4 and LZ4HC compression times.
Tokenizer's approach of looking back is horrible and breaks the
following simple case (bug I had that lead to this patch):
"string\\"
As the parser would get the end quote and check the previous character
if it was a backslash and it was, but it was not escaping the quote,
but being escaped by the previous backslash.
The best approach is to first check for escape and then go to
quote. Escape is simple and only the following byte, so we enter
escape, process the byte and then are back to regular mode (be it
quote or unquote).
Added testcase so we avoid breaking it again.
@bugfix cherry-pick
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.
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.
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.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
in one case data is not separately allocated but is part of the
Eet_Variant_Unknow struct where it is allocated as extra space on the
end of the data blob. in this case don't free it, otherwise do (pass
in true) as before. this should fix CID 1039728
Function edje_edit_save_all cause lots of SPANK SPANK, because
eet_dictionary_free is trying to delete string that is actually not a stringshare.
Reviewers: cedric, seoz, raster
Reviewed By: cedric
CC: reutskiy.v.v, cedric
Differential Revision: https://phab.enlightenment.org/D322
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
I added EET_DATA_DESCRIPTOR_ADD_MAPPING_BASIC because I need basic types in unions, and EET_DATA_DESCRIPTOR_ADD_MAPPING is only for structs.
I also modified the example with a float and a string.
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D313
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
When you open a theme, it is very likely that most of the data in it will be needed
at some point, that's why it is a good idea to tell it in advance to the kernel so
it could load them if it has some spare ressource.
We can't just blindly turn EINA_FILE_WILLNEED on any file or a wrong eet file would
be loaded in memory when we don't need it. So we shall keep the sequential load until
we are sure that the file is correct and then explicitely tell the kernel that the
rest of the data should be loaded in ram.
This is really useful to track down a leak of a memory piece allocated by an
eet_data function. If you know the size of the leaked structure (valgrind
give you the total allocated size and the number of structure in it, so you
need to divide before having the right number), you just need to do :
EINA_LOG_LEVELS=eet:3 my_app 2>&1 | grep the_size
And there will be very few line matching reducing what you should be looking at.
Stefan Schmidt
Carsten Haitzler
Cedric BAIL
Jean-Philippe Andre
Vincent Torri
Chidambar Zinnoury
Philippe Caseiro
Jérémy Zurcher
Cedric BAIL
Felipe Magno de Almeida
Gustavo Sverzut Barbieri
Albin Tonnerre
Gustavo Sverzut Barbieri
Daniel Juyung Seo
Vorobiov Vitalii
Christophe Sadoine
Chris Michael