Alright, so this is a massive patch that is the result of
trying to get rid of unused or poorly implemented classes in
ector. Originally ector was meant to support VG but extend to
things like filters as well. At the moment, ector's design
makes it quite hard to plug in the filters.
For now I think it's easier to implement the GL support for
the filters directly in the engine, where I hope to interfere
as little as possible.
This massive patch keeps only the required minimum to support
a versatile gl buffer that can be mapped, drawn or rendered to (FBO).
It's extremely inefficient as it relies on glReadPixels and lots
of texture uploads, as well as conversions between ARGB and Alpha.
Another type of GL buffer is a wrap around an existing GL image,
but that one is read-only (map or draw: no write map, no FBO).
No, all the filters run fine, and the high-level implementation
(evas_filters.c) does not need to know whether the underlying engine
is SW or GL. One problem though appears with the blending or blurring
of some Alpha buffers, the colors are wrong.
This patch removes more lines than it adds so it must be good ;)
This is an attempt at refactoring the filters code so I can
later implement GL support. This patch adds a few extra changes
to remove avoid calling functions of libevas from the software
engine: use the draw functions from static_libs/draw rather
than evas_common APIs.
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
This is a preparation step for (experimental) textblock support.
Textblock objects won't have a single filter, and the buffer's
geometry wouldn't be that of of the object itself. Thus a few
internal APIs need to be reworked first.
We do not have any upstream application using those headers and if any do,
they should have proper auto detection of them being available or not. Today,
most application should use Ecore_Evas directly. If the need reappear, we will
reintroduce those headers one by one.
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
These engines are incredibly similar - by sharing the same engine info
structure we'll be able to simplify the wayland ecore_evas bits and
make them much more maintainable.
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
It has been a long journey, but here we are at last...
The infamous gl_cocoa engine has been migrated to the
gl_generic infrastructure. This should provide great
improvements and hopefully reduce side-channels b0rkage.
Fonts seems better, scrolling is smoother, expedite
does not segfault anymore... I haven't found a
regression with elementary_test, elementary_config,
terminology, expedite.
So ok. haha. Amusing. But this is inappropriate.
1. It's not an INTENDED effect in theme so unless the theme ius doing
it - it shouldn't happen.
2. There are places to do this and it's NOT inside an engine. There
are high level filter and other mechanisms.
3. Actually this shouldn't be even done client-side. It should be done
compositor-side when moving a window around. Knowing velocity vector
etc. is useful to a client so the protocol can stay but doing the
animation client-side is "wrong". Some windows wobble and others do
not based on toolkit? really? sure we have to live with the CSD
difference but this? The compositor can do this JUYST fine. leave it
to compositor... OR do this properly with filters client-side. e.g. a
2d displacement map with evas filters would do the job as long as it
interpolates. If you want a way of forcing ALL objects in the canvas
to redirect to an intermediate buffer then do it up there at the
canvas level. It then works in GL and software, as opposed to only GL.
Also.... this is now causing issues for users:
<memeka> hi, from
https://git.enlightenment.org/core/efl.git/commit/?id=fb76fe55a52ac212b6870f1d74470a79ea5c5246
i run EFL_WAYLAND_DISABLE_WWW=1 terminology -> but it crashes in
wayland_egl/www.c in the setup_shaders function .... HELP?
so the fun was fune until we do a release (now) and until this causes
problems for users. Back to tried and tested code.
If you want to do this... do it right at the portable layers above.
...
Revert "wayland-egl: Fix use after free"
Revert "wayland_egl: Fix redirect to texture"
Revert "evas-wayland-egl: Add www protocol handling to wayland-egl engine"
Revert "gl_common: Add API for redirecting render to texture"
This reverts commit 2760afbb0e.
This reverts commit c937248eac.
This reverts commit c67f50b40a.
This reverts commit 0f7f4b6de0.
While the shaders automatic regeneration is very useful when
working on shaders, it has been the source of too many
build breaks.
So I'm making this regeneration an opt-in.
You work on shaders?
Set the env var EFL_SHD_REGEN=1
This reverts commit 3c13ef14e3.
This introduced new build breaks, especially with in-tree builds.
In particular, DIR was not defined. See T3975.
I'll make the shaders regen an opt-in rather than on by default.
So... adding the .x files to BUILT_SOURCES means they would
get deleted during clean. This was bad, but turned to be awful
when this made the check for writability fail.
See:
8a273158782b8912462e
This commit reverts:
0b69356f1b
Notes:
Please revert if this breaks the build for anyone.
I'm pretty sure the use of top_srcdir is not recommended the
way I've done it.
I hate autofoo.
We hit another argument too long error with CLEANFILES. Moving the generated
files for js and lua into separated variables and cleaning them manually fixes
the issue.
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
This will trigger a re-run of the shaders shell scripts even
in case of out-of-tree builds. BUILT_SOURCES is used here
because for whatever reason make does not rebuild the .x targets
in case of out-of-tree builds (even if the timestamps of
the dependencies have changed).
This is legacy stuff. I wish we could hide it from our inheritance
entirely. Instead, just make it abstract, remove all functions from
eo (doable here) and rename with the keyword "internal" in the new
ugly java style name.
The implementation depends on creating different code paths from the now-legacy
behavior of text appending.
The annotation system introduced in this commit replaces the current way of
applying formats on text.
Up until now it has been quite a hassle for the user to control the formats, as
it required keeping track of the format positions with an opener and closer
formats almost every time (with the exception of own-closing formats).
The combination of Efl.Text API along with the Efl.Canvas.Text annotation API
essentially replaces the capabilities of the old format.
There is additional annotation API to allow more control, so be sure to check
the documentation/.eo files and the wiki page of Efl.Canvas.Text.
The style API now accepts actual strings of format style. There is not longer
need to instantiate as style with style_new() followed later by style_free().
@feature
Summary: This fixes compilation on Windows: timeout.c is using SIGALRM which is unavailable on Windows
Test Plan: compilation
Reviewers: cedric, jpeg, stefan_schmidt
Differential Revision: https://phab.enlightenment.org/D4058
We assume that the directory already exists here when creating the symlinks.
Better make sure this is really the case.
Thanks to Vtorri for pointing towards the fix.
Fixes T3880 and T3875
This is again to avoid the "Argument list too long" error we are hitting more and
more now. Given we just merged elementary, emotion generic players, evas generic
loaders and elm_code it is not surprising we are hitting it again.
This time the number of files being hold in DISTFILES has just grown to big so a
make dist was no longer possible. If one looks at what the DISTFILES variable
from automake holds you can image it grows a lot with all the source files plus
generated files we have in tree now.
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
To cut off a big chunk but still keep all the other automagic in place for
SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle
the files in a dist-hook now.
Another thing to note here is that this also only happens as we have the one big
Makefile with includes. If we go back to per directory Makefiles this problem
should vanish as well. In any case we need a solution for 1.18 now and this is
what I have to offer. If you have a cleaner solution in mind feel welcome to
test it out and if everything we need keeps working (make, make examples,
make check, make benchmark, make dist and make distcheck) go ahead.
Autotools really really really sucks.
Because of the above, we need to manually list both source dirs and
build dirs, because some of the include files are in the source dirs and
some are in the build dir (generated).
This is a new incarnation of 0a03e63350. Our list
has grown to big again as people insist of adding the generated eolian files to
DISTCLEAN while BUILT_SOURCES will get removed durign the clean anyway.
Adding this file list twice will just make the argument list for rm to long to
work.
This moves Efl.Pointer.Event back to Evas. Originally I wanted
to share this class with Ecore but eventually I didn't need to
do so, since only ecore_evas (which depends on evas) really needs
access to these.
The internal data struct is not moved out of efl (yet?)
The eglfs, drm and gl_drm engines were all linking to eeze internal
libraries however none of those engines actually use eeze at all so we
can remove the linking there.
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This adds a separate backend to the "shm" engine that allows allocation
of buffers via libdrm that can be turned into dmabuf handles and used
with the wayland dmabuf extension.
Currently only the intel buffer manager is supported.
The benefit of dmabuf buffers is that they don't require a texture upload
like shm buffers do, and when we have plane support they can be dropped
directly into a plane without a memcpy.
Summary:
Add post processing render function as rendering full screen quard after
rendering to texture.
Add possibility use size of current frame in shader.
Add FXAA shader source files
Reviewers: raster, cedric, Hermet
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3847
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>
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
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).
So I forgot to clean my hard drive from previously generated files,
and obviously everything still worked. This lead to having to roll back
evas_smart_clipped.eo as a public eo object until we merge elementary.
Still I would like someone to take a look at elm_pan.eo and figure out
how to not rely on smart clipped there.
EGL Fullscreen is a module intended to support many proprietary GL driver that come
with custom API to create framebuffer/window. This one is starting by covering Android
with libhybris/hwcomposer. Later on, it should be able to support easily the Raspberry Pi
driver.
At this moment this does not work properly. Activate it at your own risk ! Do not report
bug if you don't know what you are doing :-) A backend for Ecore_Evas will come later on
along with a patch for Ecore_FB to use libinput. Finally a few patch should hopefully
enable this backend to work and compile more easily (relying on proper header detection
and dlopen/dlsym for access to proprietary function).
You can read more about the goal of this patch by reading our wiki at :
https://phab.enlightenment.org/w/boot2efl/
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This replaces standard Evas_Object_Image when it is used "normally",
ie. it's an image from a file or from a pixel buffer. All other APIs
(proxy, snapshot, 3d, gl, ...) are disabled on this object.
Also, reduce number of failing calls when the object is not a legacy
object, but a legacy function is called. This is because a lot of
image APIs are called internally using the legacy APIs, often in
order to reset the state of the image object (eg. set file to NULL,
etc...)
Efl.Canvas.Snapshot and Efl.Canvas.Proxy are specialized
classes previously implemented as features of Evas.Image.
Note: this half of the work, as I suffered from a bad
merge and rebase with my work branch on top of master.