This fixes the build for Windows. Thanks @vtorri for the report.
I'm not using "unsigned int" as uint was mostly used like DATA32,
ie. color data (one pixel color or a pixel buffer).
Rename a few things:
- draw helper -> efl_draw
- Ector_Rop -> Efl.Gfx.Render_Op
- ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops)
- ector_memfill -> draw_memset32 (and invert arg order to match memset)
The main rasterizer file is now draw.h in static_libs/draw
This is a non functional change, simple code refactor.
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.
Summary:
This lib would be used in efl_network_websocket.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3244
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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
Apparently the Debian package, while up to date, for some reason does
not ship the .pc file (according to q66).
According to Stefan, Fedora doesn't even have libunibreak, but only the
previous naming and old version.
Will have to wait a few years more. :(
This reverts commit a2a9f33802.
Looking through the git log it is unclear which release we used before as nobody
stated it there. :/ We updated after the security issues last year so my best
guess is that we have something like r119.
To see what changed I now included the NEWS file and also the LICENSE file from
upstream. Upstream in now hosted here: https://github.com/Cyan4973/lz4 and
http://www.lz4.info
I recommend STRONGLY that you check if your distro ships liblz4 as an up to
date library package and use the --enable-liblz4 configure option to use the
system version. I consider making the system version default for upcoming
releases and only carry the internal one as fallback for systems that do not
provide it.
Fix T2374
We need any version of libunibreak. The first one has been released in mid 2012.
Even slow distros like ubuntu already have an LTS out with a good enough
version, so I consider this enough to remove the maintenance cost.
This has been discussed on IRC.
@feature
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
Summary:
Mainly from the examples but also from libunibreak and tests/eet.
I'm not sure if it's really worth to remove warnings from the examples
-- because it adds pedantic-ness to something supposed to be didatic,
but I leave for you guys to judge.
Reviewers: tasn, cedric
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D896
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
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...
Carefully compared 'svn export' and 'make dist' results and couple of
files were missing.
Changes:
* Makefile.am: removed all .pc from EXTRA_DIST, we shouldn't
distribute them here as they will contain ./configure data such as
install location.
* src/Makefile.am: moved all if-endif to files, otherwise EXTRA_DIST
won't work properly. We must EXTRA_DIST outside of the if-endif
block.
* static_libs/liblinebreak: removed couple of unused files.
SVN revision: 82241
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Jean-Philippe Andre
Stefan Schmidt
Subhransu Mohanty
Srivardhan Hebbar
Cedric BAIL
Stefan Schmidt
Tom Hacohen
Mike Blumenkrantz
Cedric BAIL
Boris Faure
Jean-Philippe ANDRE
Matvey Konovalov
Savio Sena
Cedric Bail
Cedric BAIL
Mythri Venugopal
Rich Geldreich
Gustavo Sverzut Barbieri
Vincent Torri