I guess (can't test) that multi touch was broken, as the
position of the event was set to the position of the pointer
on the canvas. Which means all fingers would be in the same
spot, no matter what the real input. Copy & paste error.
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This removes useless magic checks (only check whether the
arg is not null) that were not even present in every function.
The cost should be similar or lower than an eo function call.
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.
This is for Wacom graphics tablets (with a pen).
The raw data sent by ecore to evas (and then to apps) is pretty
useless as it's not normalized, and apps have no way of knowing the
dimensions of the tablet, without themselves opening the device
(we don't know nor expose the path to the device).
This is for Xi2 only for now, as Wayland support hasn't been done
yet.
The intent is to deprecate LABEL_X and LABEL_Y. I'm not sure yet
if the normalized value is useful or not (it would seem we may not
be able to provide this info in Wayland).
The new WINDOW_X, WINDOW_Y labels will be used in the new event
type (Efl.Event.Pointer). Normalized values are not exposed yet,
let's decide if we want them or not first (based on what can be
done in Wayland space).
@feature
This converts Evas_Axis or Ecore_Axis info arrays into basic
pointer data. Also marks those fields as set. All events need
to properly implement the value_has property (mark all bits
whenever a value is known).
This sets a bit whenever a callback listener is added.
I couldn't get any profiling data easily (too small for
valgrind).
Note: This removes the proper refcounting on the "move"
event listeners. I believe this is not a problem as most times
the move_ref goes to 0, it is because the object is deleted.
Worst case, we just trigger a callback_call with no listeners.
This adds 32 bits to each evas object private data.
This event should not be exposed at all, it's not necessary
anymore, EFL_EVENT_DEL already exists and should be good enough.
This does move the callback call a little bit ealier in the del
process, but at first glance, this shouldn't have any impact.
This moves MULTI events to those new finger event types,
and also sends a finger event for finger 0 (aka the pointer).
NOTE: This may require a separation between a mouse input and
an actual finger touch. To be defined, ie: do we let the app
check the input device info to decide whether the event is
actually the first finger of a multi touch device, or do
we want to send only actual finger events from multi touch
devices only?
@feature
This is getting trickier, as those events have a lot more
side effects and complexity than a simple wheel event...
Some code has been added that should be fixed in the following
commits.
It's entirely possible that a system doesn't have a cpu 0, so
when we try to pin all our render threads onto processor 0 we
may fail.
This results in some very connfusing build breakage when
edje_cc hangs up because its render thread didn't start.
So, if starting the thread with affinity fails, let's try without
affinity.
(This is trivial to reproduce - just use sysfs to turn off cpu0
after boot.)
@fix
this speeds up downscaling of images by somewhere between 1.8 to 3x
dpeending on case and cpu etc. - this is ONLY for downscaling of an
image buffer betweeb 50% width and/or height up to 100% of width and
height. it's a special case optimization that cuts down the complexity
of the full super sampling filter to just do a bilinear interpolation
which is actually strictly correct for this size range and shouldn't
drop quality. it uses fixed point (16.16) to do the sup pixel sampling.
no mmx/asse or neon, but we could actually easily use it as we do use
mmx/ee and neon in the bilinear upscaler to do interpolation so this
would work here too. it just requires time and effort to make yet 2x
more special cases and use the ASM to do the hard slog here.
@optimize
Summary:
Visual position of ellipsis item should be set according to
its bidi direction. But, by setting visual position in same way
as logical position, the end ellipsis could be put opposite side.
Also, start ellipsis must placed on left side of RTL text.
@fix T3187
Test Plan: Test an sample on T3187
Reviewers: tasn, woohyun, herdsman
Subscribers: raster, Blackmole, z-wony, cedric, jpeg, minudf
Maniphest Tasks: T3187
Differential Revision: https://phab.enlightenment.org/D3769
Summary:
We can't assume the given font is same with current fdesc by comparing string.
Since Evas starts to supporting "auto" for language,
the given font string should be parsed once before comparing it.
@fix
Test Plan: N/A
Reviewers: tasn, raster, cedric, herdsman
Subscribers: jpeg, minudf, z-wony, Blackmole, woohyun
Differential Revision: https://phab.enlightenment.org/D4227
Summary:
If native surface is multiple buffer pixmap such as named pixmap, Evas should recreate eglImage everyframe.
Because DDK get the buffer ID once at eglImageCreate time.
So if internal buffer ID is changed, should recreate eglImage.
Test Plan: Wearable Tizen.
Reviewers: wonsik, raster, cedric, jpeg
Reviewed By: jpeg
Subscribers: spacegrapher, dkdk, cedric
Differential Revision: https://phab.enlightenment.org/D4211
Since the new event type is the same for multi and single
touch (finger id is the only difference), multi touch listeners
would get triggered even for single mouse events.
Fixes https://phab.enlightenment.org/T4345
Fixes https://phab.enlightenment.org/T4378
This raises a question though: How do we want to differentiate
between single & multi touch events in the eo interfaces?
The previous patch 1185c40e50 shows how having
two event types for the same thing (key or mouse input events)
was a bad idea. The only guaranteed order of callbacks is the
priority but even that was not enforced (since legacy or eo
style event had to come first).
Fixes T4310
Previously, it was limited to the part block. It was a mistake
and should have been put in the description instead, as this
allows it to change during state transition (like visible, or
proxy_src_visible).
@feature
The new event info being an eo object, it needs to be properly
cleaned. I believe this memleak would not show up much in massif
or other checking tools, as it's a stringshare leak. Also, most
of those event objects will in fact be reused and never deleted.
@fix (backported as c58e293d34)
handle smart member add if the object is invalid withotu crashing.
also don't abort and crash with other invalid states like of smart
object or child is to be deleted, has no layer etc. - continue on
safely without a crash.
@fix
thsi fixes invalid memory access to already freed memory in a parent
call where a child freed it by reference counting the struct to
ensuire it stays alive in the parent func using it.
@fix
if clipped color changed and not object color on image objects, then
the updates could be missed. this also fixes some corner cases where
opaqueness should not count for update deletion too. this bug seems to
have been here a while unnoticed.
fixes T4246
@fix
This affects pointer & key events.
Here's the scenario: in Enventor, an elm_button object
grabs the up & down keys for the autocompletion feature.
But the entry will also listen to up & down to move the
cursor. Moreover, the scroller listens to up & down arrow
keys to scroll around.
So, when calling the new eo event first, the scroller
or the entry would catch it and do some action. In
Enventor, this triggered a hide on the magic anchor
object. Bad, bad.
I fear something will be wrong with this order as well.
Both events (legacy & eo) should be called simultaneously,
following the order & priorities that were set.
This being said, in real life most of EFL internals will
move to the new eo events (right now elm relies on the
new events, but edje doesn't, yet), so any app grabbing a
key probably wants to handle the event before elm. Same
for an app using focus manually.
Fixes T4310
Due to the way the clip geometry calculation changed
(see 25d77bc1d2) to be
based on the bounding box rather than the raw geometry
of smart objects, the internal function
evas_object_is_in_output_rect() now returns true if the
rectangle intersects with that bounding box, even if
it's outside the raw geometry.
This breaks the drop area in E's pager, as it relies on
evas_objects_at_xy_get() to find which objects are at
this point. What I saw on my desktop was that only the
lower 10 or 20 pixels were droppable in the pager,
as maximized windows would have shadows covering the
upper 20 pixels or so.
Arguably objects_at_xy_get could also return all objects
at (x,y) including smart objects that extend beyong their
geometry. This can be added as a flag in the EO API, but
not in the legacy API.
while removing children from a parent smart object, the destruction of
the smart obj encountered childrne with NULL parents. they were in the
child list but had no parent. This was totally odd and unexpected,
thus caused an infinite loop trying to dlete a child that won't be
removed from the list because parent is NULL thus it cna't find the
parent list to remove it from. This works around that and then
complains with an error. The workaround also seems to have encountered
what might be a compiler bug so I prepended to the layer object list
rather than appended. this at leats stops the hang.
@fix
The specific handling for (0.0 <= ellip < 1) doesn't support multi-line cases.
One of the main reasons is that we haven't had the chance to define the wanted
behavior for multi-line.
This is a temporary hack to fix a segfault. The behavior is still undefined,
though.
Fixes T3885.
This is to avoid ERR messages such as "object is not an image!"
that can happen when a legacy image function is called on an
eo image (proxy, 3d, ...) object.
Note: This does not fix any known issue, but it's probably a safer
solution.
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
In elm_image, efl_file_get() was called on a legacy Evas Image
object, which generated an ERR message. This was way too much
noise for something that actually works.
It's best not to call efl_file_get/set API on a legacy
object, but it can be convenient for smooth code transitions
from legacy to pure eo.
Also, add safety to those APIs.
Test case: elm_test genlist dnd, start dragging anything.
ok. so here's the issue at least now. we have eo objects in the canvas
and they have a refcount of 2 user_refcount is 0. the calls stack does
NOT show we are calling callbacks at that time on these objects. they
are not in the backtrace (the canvas is, the objects themselves are
not).
SOMETHING is keeping 2 eo "internal" refs on these objects and i have
no idea what/how/who. it's a royal pain in the butt to find out as the
only way is lots and lots of logging and you get drowned in the
logging...
so what I have now done is a super ugly workaround that detects these
zombie objects that refuse to die and just FORCES them to die when the
evas canvas frees and clears out layers.
ac10a00acc doesn't really cause the
issue, it just brings it out in the open for all to see far more
easily. but something is deeply wrong SOMEWHERE with SOME objects and
our refcounts.
this fixes T4187
is_visible returns 0 if no_render is true, so should
was_visible as well. Yeah, there will be problems if
no_render changes on the fly. Don't do that.
Fixes T4193
so if an img obj had some update regions and was opaque, it didnt del
an update region first before adding the updates, thus possibly
letting update regions pass through the opaque image area
@fix
Coverity reports that we are missing breaks in the switch blocks here,
so add missing breaks.
Fixes Coverity CID1347413 and CID1347414
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this fixes over-rendering (where we render the whole image) if it has
a border set. do proper region updates if the image has a border but
is not scaled and the fill is at 0 0 and sams size as the object etc.
etc. so this is simple and doable.
this fixes T4123
this just makes it more obvious where its handling the opaque middle
fill case. see T4123 - i was just reding the code and this seemingly
does the right thing.
This fixes the following ERR message:
ERR<30400>:eo /home/jpeg/e/core/efl/src/lib/eo/eo.c:462 _eo_call_resolve()
in ../src/lib/evas/canvas/efl_event_input.eo.c:3: func 'efl_event_flags_get'
(1483) could not be resolved for class 'Efl_Event_Hold'.
This is an EO-API only fix.
This fixes the following ERR:
ERR<23969>:eo /home/jpeg/e/core/efl/src/lib/eo/eo.c:462
_eo_call_resolve() in ../src/lib/efl/interfaces/efl_event.eo.c:5:
func 'efl_event_instance_get' (1479) could not be resolved for class 'Efl_Event_Hold'.
i don't know for sure if this fixes T4103 but in theory i think it
might given a reading of the backtrace and a guess at what might
happen, so try this fix. it doesn't hurt and can only help.
@fix
This removes the need for khronos_[u]int64_t as well as the special
typdef EvasGL[u]int64.
Hopefully this should work on all platforms (note: [u]int64_t is
used in Eina APIs, so it is already required for EFL apps).
Fixes T3200
This should fix T3309
Snapshot objects are image objects, so the function is_opaque
exists. No need to bypass it. Also, alpha rectangles are not
opaque. Assume that anything with a filter is not opaque.
All of this fixes T3309 but the main point was on snapshot
objects (probably because the only point of a snapshot is
to apply a filter on it).
This is essentially a cleaner redo of ef817f15f0.
Logic should be exactly the same as there, the different is that this
one shares the code between OT and non OT.
Please refer to that commit for more information.
This was not done correctly. This split the code, which is essentially
the same for both OT and non OT. It's the same logic with some minor
additions for OT, so most of the code should be together.
This reverts commit ef817f15f0.
Fixes T4068.
Simply querying the last glyph to determine the width of the glyph sequence
won't always work, as OT can have negative offsets (adjusts the placement of a
specific glyph better).
The solution is to calculate the "max width" of some sequence that will
guarantee us proper width results. The worst solution would be to iterate on all
the glyphs and sum up the max width. This is a bit impractical. Instead, we will
inspect just the "cluster" of the last glyph, if one exists.
This should have no performance impact on trivial cases, and very little impact
on the others.
@fix
The cursor position was not set correctly to the respective fnode, causing
annotation to not be applied correctly with text that has more than one
paragraph.
The trivial case of [pos,pos] (i.e. range of length 0) didn't work if there is a
format item in 'pos'.
The condition was fixed to not include such items. The reason it was not
apparent for text items is that these have further handling in the rest of the
code and would've been disposed of.
@fix
Summary:
Font size is scaled according to scale factor.
The linesize, linegap formats also have to be scaled properly.
@fix
Test Plan:
Test cases are included.
Run "make check"
Reviewers: woohyun, Jieun, tasn, herdsman
Reviewed By: tasn
Subscribers: raster, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3688
Summary:
BiDi text is truncated because the way we find the last visual item in text object is wrong.
This patch is similar with _line_native_last_visual_get function in textblock.
Reviewers: cedric, tasn, herdsman
Subscribers: id213sin, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3947
so smart object bounding box wasnt updated properly in several other
cases. fix those other cases too by dirtying bounding box region.
this continues on from:
f6b3c3156125d77bc1d29f0fd66ab8
this fixes T4017
@fix
this is a continuation fix from
25d77bc1d2 and
9f0fd66ab8
this fixes yet more corner cases after the above 2 fixes. our clip
cache tracking code seems to be broken somewhere and not updating - at
least when events are processed so i did ti the slightly slower way
and recursed through clippers to figure it out in this path. it all
works now it seems but it's got a small speed hit. better be right
than a little faster.
@fix
i've fixed almost all the eina init/shutdown pairs to do the right
thing now... except one (ecore_shutdown) with comment inline where
eo_shutdown is not called. if this is called we are in crash land.
this needs further inspection.
Scenario:
smart {
text
proxy -> text, src_invisible
}
proxy -> smart
What we should see:
smart {
(blank)
proxy -> text
}
proxy -> {
(blank)
proxy -> text
}
What we saw:
smart {
(blank)
proxy -> text
}
proxy -> {
text
proxy -> text
}
Solution:
Check in evas render, when we're inside a proxy render, and the
proxy src_invisible flag is on (evas_object_source_visible_set(0),
that we're rendering the object itself to its proxy surface. If not,
it means we're rendering another proxy surface, ie. a parent smart
object's proxy surface.
Still loving evas render.
Fixes T4006.
@fix
Those are marked as EINA_DEPRECATED since they are for legacy only,
and EDC is the preferred method.
Note: these are new in EFL 1.18.
I would rather have not added them as legacy APIs. This patch is
here to align to Tizen which added them by mistake. Also, remove
the "name" argument from filter_program_set as it's not required,
and also not there in Tizen's code base.
Sorry for the mess.
It relies a bit on evas legacy APIs and will only work on
evas objects (Efl.Canvas.Object) for now.
The main difference with Evas_Map is that there is no
separate map object, as the functions apply directly to
any canvas object.
For convenience, most functions will automatically populate
the map if there was no previous map info. While this may
be convenient, the object's size changes still need to
be tracked to update the map info.
Summary:
Some fonts can have weird style and weight value.
If a font has a style name as "medium" and a weight value as "semi-bold",
Evas can't load the font using "font=Somefont:style=Medium".
It only can be load with "font=Somefont:style=SemiBold" or
"font=Somefont:weight=SemiBold".
On the other hand, it could be loaded when I tested the following commands.
fc-match -s ":family=Somefont:style=Medium" or
fc-match -s ":family=Somefont:weight=SemiBold"
Evas also should load font based on font's style name.
@fix
Test Plan: N/A
Reviewers: tasn, herdsman, cedric, woohyun, raster
Reviewed By: raster
Subscribers: Blackmole, z-wony, jpeg
Differential Revision: https://phab.enlightenment.org/D4108
evas-images2 example was broken due to excessive clipping.
This is one more issue with the cached clip geometry.
By default proxy_src_clip is true. The doc (that I wrote)
mentions that it means both objects (image proxy & source)
share the same clipper. So, this does not mean that the proxy
is clipped to the geometry of the source (this can be useful
in some cases, when replacing an object with a proxy to apply
some kind of effect on it... but this could be rare).
Thanks Amitesh for the report.
@fix
This fix is wrt the non-updation of the proxy object.
If a source of a proxy object has mapped objects among its children,
Rendering frame won't be correct while they were keeping changing.
The reason is, evas_object_smart_changed_get() couldn't figure those changes
out correctly because of cached-clip visibility.
Cached-clip of smart member can't be used for map surface updation,
because cached-clip includes the visiblity status out of the smart object.
So, loose the criteria to make it rendering smart members in map.
Summary: Which will apply translate property twice once to shape and once to origin.
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4086
Summary:
Including camera and light to calculation aabb can lead to confusing in detemination
bounding of the whole scene (root node).
@fix
Reviewers: cedric, Hermet, raster
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4060
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The issue is that in some cases we were calling user code (callbacks)
when some of the nodes were referencing already deleted text nodes. This
caused invalid memory access. This commit delays the callback calling
until after all of the cursors got into a consistent legal state.
This goes back to a stupid comment I made in 93fad2a19f2507a:
No idea why evas_box was overwriting smart_data.get
(esp. since it was returning a private struct).
Well, it turns out the struct is NOT private and the smart
data pointer can be used by any user of evas box (including
Efl.Ui.Box).
Fixes T3926
This was discussed and still wasn't decided whether this is required to be
supported internally.
The reason for this revert is that the behavior still needs tweaking to work
just right along with the legacy behavior.
The cursor update hasn't considered when the pararaph is broken. The reason the
code path is different from legacy is because that it was originally intended to
support append and prepend operations in the new API. Since we don't anymore
(only supporting append operations in the new cursor with 'text_insert'), we can
simplify the insertion implementation and fix this.
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.
efl.gfx.fill will reset the filled flag, so the internal function
needs to be called instead of the gfx api.
This test error was added in a very recent commit: ccaf12e1b6.
This is a better fix than the previous patch, as it keeps
the legacy API check. The point of that check is: if the object
has been created with legacy API (evas_object_image_[filled_]add,
then legacy APIs are allowed, otherwise they are disallowed. This
means only EO APIs should be used on an eo_add() image object.