Summary:
Currently user ask for the root_node from the evas_vg object and then attach its tree by setting the root node as parent.
With this change this process will be explicit. user has to set the root node to the evas_vg object and the object will take the ownership
of the tree. User can query the current vg_tree by root_node_get api.
Test Plan:
Fixed the test app to reflects this change.
Reviewers: jpeg, cedric
Reviewed By: jpeg, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5347
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
EFL-using things wouldn't build after addition of the new gesture
stuff because gesture headers would get installed into the
$PREFIX/evas-1/canvas instead of $PREFIX/evas-1/gesture
directory and Evas_Eo.h is including headers from the gesture/
directory. This fixes the problem by installing the headers into
their correct location.
Spanks go to @jpeg for not reviewing things properly.
Efl.Animation.Group.Sequential is a class for animations started in
sequence.
Efl.Animation.Object.Group.Sequential is a class which provides
methods for an object of Efl.Animation.Group.Sequential.
The objects added into the sequential group animation object start
in sequence.
Efl.Animation.Group.Parallel is a class for animations started in
parallel.
Efl.Animation.Object.Group.Parallel is a class which provides methods
for an object of Efl.Animation.Group.Parallel.
The objects added into the parallel group animation object start in
parallel.
Efl.Animation.Object is a class which starts or cancels animation.
Efl.Animation.Object instance is created by Efl.Animation instance.
So Efl.Animation.Object instance contains animation properties from
Efl.animation instance.
Animation properties are set by using Efl.Animation instance and the
animation is started or cancelled by using Efl.Animation.Object.
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
Since the EO APIs are defined as weak symbols, invalid definitions of
EAPI lead to runtime crashes on non-public APIs. This is a fix following
a series of changes wrt. EAPI definitions.
The file have been moved into a fonts subdir in commit e8b35c779e.
Update the path here to get it included into the tarball to make sure
check passes during distcheck.
Originally it was its own object.
There are some valid claims that there is no justification for it to
remain an object.
Furthermore, it's apparent that it added little benefit: changes of
each cursors, in practice, triggered a query for all objects of the
same textblock. There wasn't real advantage to have a finer resolution
of controlling the cursors with their own events.
This ports back a lot of code, and changes a lot of other code in the
higher-up widgets, such as Efl.Ui.Text and co.
The usage was replaces from:
efl_canvas_text_cursor_char_next(cur_obj)
to
efl_canvas_text_cursor_char_next(text_obj, cur_obj)
that is, it is an operations on the TEXT OBJECT, rather than on the
(now removed) cursor object.
So, one less efl object to worry about now.
Hopefully, the port went smooth.
adding an "event rect" is a common use case for rectangles, but I needed
a smarter event rect so I sent one off to school and it came back like this.
an event_grabber is a smart object which functions like a normal event rect
which has color(0,0,0,0), but with an important difference: it can have smart
members. event propagation works differently for an event_grabber:
normal:
event -> layer -> smart(obj1,obj2,obj3) ->(?) other objects
in this case, obj1,obj2,obj3 are all "inside" the smart object and their stacking
will always be considered as being inside the smart object. rendering is also
tied to the smart object in this case, as is clipping.
an event which reaches a smart object will be sent to the objects inside,
and then may continue through the smart object if there are no objects which
block repeating.
event_grabber:
event -> layer -> event_grabber -> obj1,obj2,obj3 -> STOP
in this case, obj1,obj2,obj3 are unmodified after being added to the event_grabber
and can be stacked, rendered, and clipped completely independently of the
event_grabber.
the event_grabber is considered an "event_parent" for this case. member objects
are not "inside" the event_grabber, and they are unable to receive events on
their own. instead, the event_grabber, which must be stacked above all its
members, receives events and propagates them top->down through its member objects.
if none of the member objects block the repeat of an event then the event will
still be blocked from further propagation past the event_grabber.
object lifetimes are independent of the event_grabber; deleting the event_grabber
has no effect on its members.
@feature
Wait a second though, this implementation is not only incomplete
(no support for box vs. gaussian blur), it's also insanely bad in
terms of performance. Small radii may work fine, but at least blurs
render properly in GL with this patch (no more glReadPixels!).
The shader needs a lot of love, including in particular:
- support for 1D box blur single pass
- support for 1D gaussian (or sine) blur
- use linear interpolation and N-tap filters
- separation of 2D blur in two passes (high-level logic)
- potentially separation of large 1D blurs in 2 or more passes
knowing that 2sigma == sigma + sigma when it comes to the gaussian
bell curve.
This one was a bit more... "fun". I had to add a new vertex
attribute and obviously using a VertexAttribPointer led to
incomprehensible crashes. But a simple glVertexAttrib2fv makes
it work like a charm!
A rare option is not handled yet.
This reuses the existing mask infrastructure, but adds a color
flag to use the whole RGBA range, rather than just the Alpha
channel.
Filters are still very slow (glReadPixels and non-optimized use of
GL buffers...), but this is progress :)
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 ;)