in today's modern world of fast-paced, HTML5-driven, C++-riddled
development, nobody wants to spend hours typing out long words like
"description" or "mouse_events" or "name". there's no time for it
and certainly nobody is going to allocate budget for this sort of
keyboard-related nonsense.
enter lazEDC: the solution for edje-loving keyboard jockeys everywhere.
by breaking the parser of edje_cc with the strength of 10 frenchmen,
new, shorter keywords such as "nomouse" can be used in place of lengthy,
rambling statements like "mouse_events: 0", and things like
part { name: "clip"; type: RECT; description { state: "default" 0.0; }}
can now be written as
rect { "clip"; }
with the exact same effect.
initial tests show that complex and terrible edc files such as the infamous
"genlist.edc" can be reduced in size by over 15% using these new features.
see edcref for docs, and genlist.edc for examples
@feature
@awesome
It includes too fixes for the complex type. If I had listened to Tasn,
I would have detected them a long time ago.
But he didn't insist enough. He just said:
"Write your tests, ?#@*&%! french!"
the declared t3d_scene api names are not matched exactly between header and code.
these name should be just "3d_scene"
and still there was a Evas_3D.h reference in evas Makefile.
There is an ifdef HAVE_ETC2_DECODER to disable unimplemented code.
Since these ETC2 decoding function are not implemented yet,
they should be disabled at compile time.
Yes, this means Evas will not be able to load those images in case
of SW engine or GL engine w/o ETC2 support.
@feature
Enable 3D features using --enable-evas-3d=yes when configuring.
APIs are exposed through Evas_3D.h.
Currently, evas-3d is being supported only on gl_x11 engine.
Conflicts:
src/lib/evas/Evas_Eo.h
Gif decoder decodes prior frames sequentially to decode a specific frame.
The last frame of sequential decoding, which is the frame we want to decode,
remains un-decoded until the while loop stops.
The frame count should be incremented after the comparison statement.
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).