As Dave pointed out, those are meant for internal use by Edje and
the plugins implementation, rather than for apps. This removes
ugly and complex code. Makes me happy :)
Note that I've kept the composition for now. We can remove it
as efl_content_get() must work on the part handle anyway. But it
can be used as a quick solution.
This effectively replaces edje_object_part_external_object_get
and allows all function calls except those from Efl.Object.
Is this good enough? Or do we need access to the real object?
This adds a new class: Efl.Canvas.Layout.External.
I hate this long name...
This class represents an external part, and for now only
supports param_set/get as well as param_type_get. For now
param_type_get() still returns an Edje_External_Param_Type and
not another more generic type.
TODO: enumerate choices, return object, return content
All windows should be standard, really. Except when using legacy
elm_win_add() or if type_set() was called with a specific type.
I dislike type_set...
Ref T5322
we haven't gotten replies yet on what our position or size should be,
so we should store them so centering works before show but after
resizing is evaluated (that also fixed by forcing an eval).
@fix
This is a copy of the "Flip Page" map usage example that relies
on the new set of APIs for EO. This was used to test the API
and show its usage.
The calculation being done in absolute values, this does not
really exploit the new API, but instead proves that it is on
par feature-wise.
The performance is worse than with legacy, because of extra list
walkings, map calculations, small struct allocations and eo calls.
This fixes the shadow of the page which was broken with the legacy
API (as color_get did not recalc the map).
A better implementation can probably be done without having
to rely so much on absolute coordinates.
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
Manual points population will eventually be useless as the
map API will become more like a transformation API, where
the current object geometry doesn't matter as much as which
transformation is applied to it.
If we disable preload, then the second file set on an elm_image
object would not trigger a deletion of the first image. As a
consequence, both images would be visible... really bad if there's
alpha or different dimensions!
Thanks Anand Kumar for the report!
@fix
After talking with @eunue I realised that the way I'd first
implemented the box/grid "pack" API was simply too complicated.
I had tried to make it possible to change the layout function
at runtime, like good old evas box, but since there are no function
pointers in EO the final design was really convoluted.
If someone really needs to change the layout of a box at runtime,
just create your own subclass, or unpack all items and repack them
in a new box.
Note: there are still some issues with the layout params & flow
This make save() work on snapshot objects, provided the call
is done from inside render_post.
Also, this saves the filtered output of an image, rather than
its source pixels. Any call to save() on a filtered image must
be done from post-render as well.
Fixes T2102
@feature
This will reuse existing buffers by resetting only the minimum
required in the filter context (also reused). Work in progress,
as the actual reuse is disabled for now.
When using a snapshot object we have access to exactly all
the pixels below it inside the snapshot surface. So, in order
to produce a nice blur, it is necessary to expand this snapshot
and then clip it otherwise the edges will look a bit ugly.
Unfortunately, there are still places where blurs didn't look
so good, as objects below an opaque region would never get
rendered into the snapshot object. So the edges, inside a
snapshot object, around an opaque region would have blur
artifacts.
This fixes that by shrinking the cutout regions by the radius
of the filter. Eg for blur this is the blur radius.
The test case in elm_test can exhibit this fix very clearly:
a red glow would be visible around the opaque rectangle, but with
these changes we instead see the blurry edges of the objects
below the rectangle.
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.
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 ;)
Summary:
When popup is timeout, notify call hide func, and send time out event to popup.
After popup receiving time out event, popup hide object again,
so hide animation doesn't show.
And notify hide function doesn't send hide signal to block events part,
(but dismiss function send it)
So add that signal.
Test Plan:
1. elementary_test -to popup
2. click first item, "popup+center+text"
3. compare time out event before this patch and after.
@fix
Reviewers: herb, singh.amitesh, Hermet, cedric, raster, jpeg
Differential Revision: https://phab.enlightenment.org/D4780
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Since 9b7ac51943 evas map tries to avoid recalculating
stuff when the map parameters have not changed. Unfortunately the
code in elementary_test -to "Flip Page" was badly written. It was
modifying a constant's internal value (after ugly cast). So the
memcmp() and all other checks would return successfully, as the
exact same pointer was being compared to itself.
So, I've fixed the comparison by adding some forgotten parameters
(perspective) but most importantly I fixed the map API usage in the
test case.
We have a tag for unstable API, use it. It'll be visible in the
doc and force users to add the macro before being able to compile
code.
This amends d8dd685966.
The things you learn to love...
The situation was:
- An object is mapped (naviframe in an animation)
- One of its children has a mask
- The window is rotated by 90 or 270 degrees (landscape)
The mask glsl code to invert the x,y coordinate depends on the
screen rotation and this somehow was wrong.
Tested on Tizen and in elm_test "Masking", made with @jiin.moon.
@fix
If an item is marked as disabled it should be re-enabled
before being put in the reusable contents cache. Otherwise
a following use of this object may result in a disabled
item being used, making the UI effectively disfunctional.
Also modify the test case to show and test this behaviour.
Add an efl_isa() to protect calls to elm_widget APIs.
Fixes T5236
@fix
Summary:
If user added item with item_insert_before and item_insert_after, item was not displayed.
For this reason, fixed box indicated item correctly from reference->button to VIEW(reference).
Additionally, remove the unused variable button in _Multibuttonentry_Item struct.
Reviewers: woohyun, CHAN, cedric, jpeg
Reviewed By: CHAN
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4708
Yay to full color characters. The list of selected emojis is
quite random. Some more could be added.
Just two remarks:
- Aren't they supposed to scale down?
- Why is my grinning face always ugly?
GLView tends to print some random garbage when using the
GLView Gears test. That's because we're allocating and printing
a 0 byte buffer. Don't do that.
It was assumed that GLES 3 would only work with EGL but in fact
OpenGL 4.3 & 4.5 are supersets of GLES 3.0 & 3.1 respectively. So
GLX should also support GLES 3.0 or GLES 3.1 for evas gl, if the
driver supports it, of course.
Of course while doing this patch things didn't go like they were
supposed to go. I'm currently using NVIDIA's proprietary driver,
that conveniently provides EGL with GLES 3.2. But wait, there's
a catch: GL_VERSION is "OpenGL ES 3.2 NVIDIA" except that none
of the functions of GLES 3.1 or GLES 3.2 are actually supported.
Those functions are only present in the GLX/OpenGL variant of the
driver. Thanks so much for making my life easier...
So yeah, this patch contains a hack for those invalid versions
of GLES 3.x. What was supposed to be a small fix became a huge
mess.
Also add a comment about the possibly invalid auto-upgrade from
GLES 2 to GLES 3.
This adds a test case in elm_test, but only to verify that
elm_glview_version_add(3) actually works. We need a proper GLES 3
test case, eventually (and 3.1, 3.2 of course).
Summary:
If orientation is TOP, BOTTOM, LEFT and RIGHT and
tooltip was moved due to located out of screen,
adjust location of arrow so that can indicate right position.
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Test Plan: elementary_test -to tooltip4
Reviewers: cedric, Hermet, jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4554
Also support both Evas.Image and EO Efl.Canvas.Image classes.
Add a test case in elm_test (under "Icon").
I'm not so happy about this patch... it shows that the API
barrier between legacy and EO implemented for images may not
be such a great idea after all :(
Amitesh Singh
Jean-Philippe Andre
Daniel Hirt
Marcel Hollerbach
Stefan Schmidt
Carsten Haitzler
Andy Williams
Cedric BAIL
JinYong Park
JEONGHYUN YUN
Minkyu Kang
Chris Michael