wayland_shm's dmabuf implementation needs acess to libdrm headers for
doing GPU specific memory allocations. We search for these libraries
at runtime with dlopen, so we don't need to find them at build time,
however certain struct definitions and defines are still required.
Those and many more will be required for proper map/unmap support.
There will be problems with planar formats:
YUV, RGB565_A5P, ETC1_ALPHA
The quick solution to this problem is to not support region
conversions, only full-image (so we can assume the location of
the various planes in memory).
This operation was faked by running a mul and a blend ops. Now
they are combined into one. A GL shader should also be able
to do this in a single pass.
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
Derek Foreman
Jean-Philippe Andre
Cedric Bail
Tom Hacohen
Stefan Schmidt
Jaehyun Cho
Vincent Torri
Subhransu Mohanty
Srivardhan Hebbar
Stefan Schmidt
Mike Blumenkrantz
Cedric BAIL
Boris Faure
Jean-Philippe ANDRE