This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
generate a static library for src/static_libs and use that as
LIBRARIES for the actual library, for those such as rg_etc that are
used multiple times will even speed up the final build by compiling
only once.
Although not used, they can be made into shared libraries that would
go inside /usr/lib/efl/support/v-1.19/libname.so
We have to use void in a function declaration if we want no function
parameters. Using just empty parenthesis means the function takes an
unspecified number of parameters.
We had it correct for most declarations and this series fixes it for
the rest.
In the nightly builds we have debug enabled and this spotted the case where
rg_etc1_solution_coordinates_block_colors_get is actually still used:
lib/eet/.libs/libeet.so: undefined reference to `rg_etc1_solution_coordinates_block_colors_get'
Showed only after we switched back from release to dev mode.
@fix
Unused functions.
I keep them around for reference, for whoever wants to work on
improving the encoder.
There are still some warnings. Clang is just crazy.
No need to write out alpha in a RGBA color when only
the RGB values are used by the distance op.
Also, add a comment on the byte order. Maybe I'm wrong
but I believe the operations are fine wrt. byte order :)
There is still some C99 code in the file in the form of
for (int k = 0; ...)
If there's a strong requirement not to use this form, I'll
change it, otherwise I find this specific code style more
readable (k is local to this iteration).
This patch and the previous one even give a ~10% speedup
on the encoding time. Sweet :)
So I guess always compiling with debug flags and no
optimizations isn't the best idea as some really bad warnings
can be hidden. Thanks raster for the notice.
And this completes the first version of this ETC2 encoder.
It's pretty slow and not exhaustive.
Color selection for T and H modes could probably be optimized
for both performance and quality. As for the planar mode, there
is no selection to speak of, as we just take the values of the
pixels directly (no scan, very fast)
On a sample image with lots of blue, white and noisy gradients,
T+H+Planar mode boost the PNSR from 41.22dB to 42.01dB.
Without planar mode, the PSNR was 41.94dB.
@feature
In this mode, two colors are encoded in RGB444, a multiplier and
distance (index) are selected. Two extra colors are extrapolated
from the main base color. As in ETC1 we have 4 base colors to paint
our block.
@feature
Implement Alpha encoding, brute force way, but doesn't scan
all possibilities either (only based on average alpha).
RGB encoding is still entirely left to the rg-etc1 encoder.
T, H and Planar mode will come in the next commits.
@feature: Implement an ETC2 encoder from scratch for RGB8 and RGBA8
Evas uses BGRA data while rg_etc1 uses RGBA data, so there
were incompatibilities between the two.
Now, rg_etc1 will take BGRA data as input and output.
So I must have been a bit tired last Friday when "fixing" some
code producing artifacts, as I was just basically disabling part
of the code without realizing it :)
Let's just disable it then.
Add some comments as I'm reading and understanding the code.
Fix some rare artifacts happening mostly with medium quality
encoding, where a few pixels (2x2, 2x4 or 4x2) will have a
horrible contrast with their surroundings (eg. pink over black).
The ETC1 encoder is expected to write all 8 bytes of the
output data. But in case of a solid color block, it was writing
only 1 of the first 3 bytes (R, G, B). So lots of solid blocks
were containing invalid data (for instance: R + dR < 0 or > 255).
Make it clear which local variable we really want to use by changing
the names. All of these seem to be fine but this can really bite us
so have better clarity here.
In 4053911e we tried to fix the debug build and failed. The function API
actually asks for coords as first parameter. Our nightly builds expose
this debug build and have been failing due to this.
It also makes clear that the debug part of this code was never really
used upstream...
Marcel Hollerbach
Marcel Hollerbach
Gustavo Sverzut Barbieri
Jean Guyomarc'h
Cedric BAIL
Stefan Schmidt
Stefan Schmidt
Jean-Philippe Andre
Mike Blumenkrantz
Jean-Philippe ANDRE
Matvey Konovalov
Cedric Bail
Cedric BAIL
Mythri Venugopal
Rich Geldreich