if gif has example 4 colors in colormap, pixels provided still can
hold values higher than 3 (4, 8, 255 etc.) ass a pixel is still a
byte. it should not, but it could. technically it'd be nice for gitlib
to pad its palette out to 256 entires to ensure this cant be a
problem, but it doesn't have to , so make a local copy of the cmap
when decoding pixels and pad out to 256 entires (using color 0 as any
value > pallette ize is invalid anyway so any color will do).
this fixes a possible security attack vector in reading memory out of
bounds of an allocated array. not very far out of bounds - but enough
to cause a crash - ie a dos attack, (not to inject code though).
@fix
This removes a fixme where we were not using wl_(pointer, keyboard,
touch)_release functions as they rely on newer versions of the wayland
protocol. As we now rely on 1.10 of wayland, these can be enabled now.
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Evas Image should be independent of render engine.
So remove native.func.data member of RGBA_Image, Evas_GL_Image
struct. And remove data argument,too.
ref f10672dd74
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Use the new post-processing API and www extension to implement
CSS effects for wayland-egl applications.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
New API allows a context to be redirected to texture. When rendering is
complete the texture can be unbound from the frame buffer and used for
post-processing effects.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
this accumulates all data relevant to client-side www into
the Evas_Engine_Info_Wayland_Egl struct so the client can react to it.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
this works with 7166e6b859 and fixes a
leak added because ... free does not free!
evas_common_draw_context_cutouts_real_free(0 now actually frees the
rects, but evas_common_draw_context_cutouts_free() before did not.
@fix (follow on from 7166e6b859)
This marks all EOAPI functions with GCC weak attribute.
This allows two things:
- replace functions
- link at runtime and check if functions exist
The purpose of this patch is to exploit these two features
of weak symbols. The first goal is to allow applications
to build binaries against later versions and run on earlier
versions of EFL without any run-time link error. Those errors
simply prevent applications to even start if they were using
any function that's not present in the old version of EFL.
Now all that needs to be done on the application side is to
do either of:
- if (efl_version > xx) { call_weak_symbol() }
- if (call_weak_symbol) { call_weak_symbol() }
In the future, we can also imagine providing a compatibility
library that would replace EFL's internal APIs with a newer
version. This would let apps use new EFLs on platforms that
don't update fast enough.
I am now pushing this patch as an experiment to see what breaks,
but I expect no problem.
@feature
Summary:
Evas Image should be independent of render engine.
So remove native.func.data member of RGBA_Image, Evas_GL_Image struct.
And remove data argument,too.
Test Plan: Local test, Tizen3.0 mobile, Desktop englitenment
Reviewers: jpeg, spacegrapher, wonsik
Subscribers: cedric, dkdk
Differential Revision: https://phab.enlightenment.org/D3850
this fixes the fix 4d6a8a7fce to be
portable to platfomrs that do not support __thread - seemingly openbsd
does not (argh!) and maybe others. so on these platforms then they
dont get the optimization of keeping a cutout rect pool to avoid
re-allocation.
this also every 4096 draws "resets" the cutout cache so it doesnt
expand and stay expanded forever.
@fix
ssometimes the evas render updates are a list of Render_Updates
structs ... sometimes Eina_Rectangles. this is horrible and i think a
bug turns up (but its not reproducable on linux - just bsd) with an
invalid free ... likely because we free() a ptr from the mem pool
eina_rectangle gets rects from. thats most likely the cause of
https://phab.enlightenment.org/T3226 - but as i can't know for sure,
this is a guess, but readiong the code i see posible vectors of
problemss here ... maybe.
so this redoes the update rects to ALWAYS be Render_Updates struct
and appropriately returns correct structures etc. etc. in api which
demand a list of Eina_Rectangles there.
pending testing on foreign sysstems to confirm this by @netstar
@fix
The edje_external module from elementary is not integrated into the build
system yet and having these files enabled here confuses our po rules.
Cedric will enable these again when he enables them in the build.
We have been putting the generated eo files and BUILT_SOURCES into CLEANFILES
several times. So far this have not been a real problem but with the elm merge
and more and more eo files showing up this did explode recently.
During make distcheck a lot of files kept being around and make complained about
them. It took some digging to find the arguments list to long error. If you want
details on this great limitation have a look here:
http://www.linuxjournal.com/article/6060
In our case we have been lucky enough that we just appened many files over and
over again. Not doing that solves the issue for now. My testing showed no
problems but if I missed something let me know.
Fixes T3386
Strange enough, if I still try to update po files, half of their content
disapear as if we are unable to find the text to translate in the .c files
when it is still there and the file is processed...
This reverts commit aaf8b86179.
it turns out that this was irrelevant and there was some less-than-competent
engine code trying to manhandle surface sizes
Carsten Haitzler
Cedric BAIL
Mike Blumenkrantz
Chris Michael
Stefan Schmidt
Derek Foreman
Ji-Youn Park
SangHyeon Lee
Jean-Philippe Andre
Minkyoung Kim
Jean Guyomarc'h
Jihoon Kim
Andrii Kroitor