Clang 3.9.0 told me:
warning: passing an object that undergoes default argument
promotion to 'va_start' has undefined behavior [-Wvarargs]
So I told it to shut up and changed Eina_Bool to int.
Note that edje_edit_state_external_param_set has the same issue.
I'm trying to fix a crash that seems to happens in some very odd
circumstances under stress testing. I have absolutely no idea
what is going wrong... So let's just add some extra safety.
Summary:
When Evas is deleted the function _evas_device_cleanup() goes thru all
devices and unref them. Since Evas_Devices are Efl_Input_Device, the user
may still hold a reference to the device (efl_ref()),
thus causing the device to do not be deleted *yet*.
This causes a problem, because when the user calls efl_unref()
and the device itself is deleted the Evas _del_cb
callback will be called and will try to access the Evas_Public_Data from
a deleted object.
In order to avoid this problem all devices will be kept in the devices
list and Evas will unregister the EFL_EVENT_DEL from those devices that
were not deleted.
Reviewers: jpeg, bdilly, barbieri, cedric
Reviewed By: bdilly, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4369
so since this uses new pos - cur pos to move BY x pixels... there is
an issue that if the move of the obj ends up re-moving the current obj
TO the same pos. it moved BY the same delta again thus racing ahead.
not great. because x/y is not stored until the call stack returns to
after the smart move func and the pos set storce the new position in
the object struct. the easiest way atm until we have relative
positioning etc. is to store this in the smart obj and use the delta
at that time of the call then store it immediately so a recursion ends
up with a delta of 0 if its the same pos, so go back to where we were.
this fixes a nasty issue i spotted in fileselector that made filesel
icons race along when scrolling 2x as fast as everything else. oddly i
couldnt see this in any other widget that scrolled when i looked...
which is odd, but... either way a nasty issue... subtle... and now
fixed. never saw this before so this seems new.
In case of a mapped object (eg. when applying a map to a window
in wayland compositor), the canvas and output coordinates are
not meant to be the same.
In EO land, applications should instead use the common interface
Efl.Input.Interface.pointer_xy.get (on the canvas).
@fix
This patch fixes an issue where border icons were missing when running
EFL Wayland client applications. This also fixes the issue where
softcursor mouse pointers would not draw over bottom window border.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
before changing MAGIC_CHECK to eo_isa passing NULL to a function would
result in nothing, now it gives a error message. This restores the old
behaviour.
Due to commit 7ce79be1a1, EFL Wayland
Client applications stopped rendering their window icons. This was due
to the code which tried to detect if an object is in framespace.
Previous version would just check the obj->is_frame flag ... which is
insufficient to determine if an object is in Framespace. This commit
fixes that issue by checking an objects geometry also.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This was broken for smart objects that are not "clipped smart
objects". This fixes the example evas_smart_object.
NOTE: This EAPI was removed in efl-1.18!
/!\ This was an uncaught API break between 1.17 and 1.18 /!\
@fix
Coverity reports this as a dereference before null check which implies
that 'cur' May be null here, so let's not use it before we check it.
Fixes CID1363765
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports this as a dereference before null check which implies
that 'pd' May be null here, so let's not use it before we check it.
Fixes CID1364114
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch fixes Coverity CID1364123 which reports that (in some
cases) va_end was not being called for var args. As they were
previously initialized with va_start, then va_end should be getting
called.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Lacking a proper internal tag, I'm using both protected (it is
in fact a protected access function) and beta (to mark as unstable,
not real API).
New smart objects based on EO only should rely on constructor,
finalize and destructor exclusively. In theory, this should be fine.
Unfortunately it may be impossible to inherit from the Efl.Ui.Win
class as it uses a really bad hack and calls super.constructor
inside the finalize method.
This is an override of efl_gfx_size_set. Same as before, the
order of operations matter so it is possible that a corner
case will break. In particular, legacy code was:
- intercept
- smart resize (do stuff), super, super, super
- evas object resize
The new code is more like:
- intercept
- super, super, super, evas object resize
- do stuff
But unfortunately this broke elm_widget (read: all widgets) as
the internal resize was done before the object resize. So,
inside the resize event cb, the resize_obj size would not match
the smart object size. >_<
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
While this kind of API seems to make sense with smart objects
(relative coordinates), it is currently not used apart from
the smart object class itself.
So, for now, I'm moving this to legacy to clean up Efl.Canvas.Group
and we can later add the equivalent in a clean "group" API.
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
Widgets should simply override efl_gfx_color_set and call
super all the way up to evas object.
Legacy compatibility with call interceptors and early call
abortion (eg. delete_me or obj->layer == NULL) are implemented
with an internal call. See the previous commit introducing the
API.
This is a poor man's solution to get rid of group functions such
as clip_set, clip_unset, color_set, etc... See the following
commits.
This API needs to be EAPI for elementary but shouldn't be used
outside EFL. This is required purely for legacy compatibility.
Here's the call flow, inside show(obj):
1. if (intercept_show(obj)) return;
2. show(super(obj));
3. do other stuff
Most of the smart functions "Efl.Canvas.Group.group_xxx" should
not exist and be overrides of the base object function instead.
Cleaning this up is necessary if we want an EO API for custom
smart objects. This patch is the first attempt at removing a
method (the simplest one).
As for no_render, I wonder if propagating to the children
really is necessary. evas_render should skip them already.
Summary:
If the pixels of image object has updates
via native_suface_set api with TBM surface,
does not update on screen(no rendering)
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4340
EO is now extremely restrictive wrt. threads so that efl_data_scope_get()
can't work outside the main loop. This patch fixes the usage to create
sw buffers as shared objects (accessible from both the main loop and evas
async thread) and use plain old pointers where possible.
The buffers now have no parent because efl_add(CLASS, obj_from_mainloop)
does not work with shared objects. This is bad, as the buffers conceptually
belong to the main loop, and only need to be accessible from the draw thread
for a few calls. The main loop determines their lifecycle.
Fixes T4628
And indirectly also Efl.Canvas.Object.
I believe those two classes should even inherit from Efl.Loop.User.
Right now this patch relies on the new dependence of Evas over Ecore,
and is maybe a bit ugly as is.
Ping @cedric
See T4686
We need a method that allows us to place the cursors at the start and end of an
annotation. This is required for things like getting the geometry of a range.
@feature
The ported geometry_get was actually the legacy simple_geometry_get.
For getting simple geometries like selection this was enough, but I forgot that
we also need to query more complex geometries e.g. links.
This is required to implement link anchors in Ui Text.
Now geometry_get and simple_geometry_get are the same as their legacy
counterparts.
@feature
Summary:
It should be evas_device_add_full() in order to follow the EFL
name pattern.
Reviewers: DaveMDS, bdilly
Reviewed By: DaveMDS, bdilly
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4325
As ector objects are acessed by draw thread we need to create it as
shared object in order to access it from other thread.
Note: there is some performance lag...
Summary: make ector object as shared eo object to acess from other thread.
Reviewers: cedric, jpeg, raster
Reviewed By: jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4319
SEGV would happen if the cache was NULL, as the error pointer
was also NULL in some cases (root cause for cache == NULL not
quite known, happens in elm_suite with CK_FORK=no).
Note: simply adding evas_common_init() to evas_init() leads to
a whole new set of issues with CK_FORK=no elm_suite - not good.
Ref T4623
v40 bytecode interpreter is official as of freetype 2.7.
The results don't look so good at the moment. The text looks and glyph
positioning seem worse than they were with the previous v35 interpreter.
So, in the meantime we'll keep using v35, just so everything looks
normal again.
Although the v40 is relevant since around 2.6.3, I rather not do any
FREETYPE_MINOR checks in this patch, because distributions might ship
previous versions with the other (v38) interpreter enabled.
We've been pinning the render thread for every EFL process to core 0.
This is a bit silly in the first place, but some big.LITTLE arm systems,
such as exynos 5422, have the LITTLE cores first.
On those systems we put all the render threads on a slow core.
This attempts to fix that by using a random core from the pool of fast
cores.
If we can't determine which cores are fast (ie: we're not on a
linux kernel with cpufreq enabled) then we'll continue doing what we've
always done - pin to core 0.
if image object's first alpha value is false, evas_object_image_alpha_set function did not work.
opaque_valid is always 1 even though has_alpha value changed.
We've been pinning the render thread for every EFL process to core 0.
This is a bit silly in the first place, but some big.LITTLE arm systems,
such as exynos 5422, have the LITTLE cores first.
On those systems we put all the render threads on a slow core.
This attempts to fix that by using a random core from the pool of fast
cores.
If we can't determine which cores are fast (ie: we're not on a
linux kernel with cpufreq enabled) then we'll continue doing what we've
always done.
I got an issue report about map rendering.
After investigated, I found that was introduced by data overflow.
For fast computation, evas map uses integer data type rather than float,
that gives up some range of data size.
So, if vertex range is a little large but still reasonable,
polygon won'be properly displayed due to the integer overflow.
We can fix this by changing FPc data type to 64 bits (ie, long long)
But I didn't do yet though I can simply fix this costlessly.
By the way, my test case map points are below.
0: -1715, -5499
1: -83, -1011
2: 1957, 5721
3: 325, 1233
and gl result is perfect but sw is totally broken.
@fix
Commit 405680e836 changed how hold
events were being sent. Previous code was sending the hold events to
child objects, however after mentioned commit, they were being sent to
main objects. This patch fixes that.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Gcc warns eo_child is set but not used here, so remove it.
NB: This should have been removed in previous evas_events commit. Oopise
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Gcc warns that these variables are 'set but not used'. After reading
the surrounding code, it turns out they are not actually used, so
remove them.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This brings support for the eo api for external buffers (like
the old data_set / data_get). The new API now works with slices
and planes.
The internal code still relies on the old cs.data array for
YUV color conversion. This makes the code a little bit too
complex to my taste.
Tested with expedite for RGBA and YUV 422 601 planar, both
SW and GL engines (x11).
For pen tablets, this exposes the values as given by the driver
(quite useless without knowledge of the device itself).
For mice, this exposes x,y as set by the display manager, without
any extra processing in terms of smoothing or prediction. IOW
this returns the same as x,y until a smoothing algorithm is
implemented (todo).
There were 2 wrong conditions.
1. visible check.
Smart changed can be skipped only if previous/current visibility are false.
2. clipper.
Actually, it needed to check previous/current clippers but previously,
it checked only previous clippers.
@fix
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
This combines evas canvas functions to list and query
touch points into a single iterator:
- evas_touch_point_list_count
- evas_touch_point_list_nth_xy_get
- evas_touch_point_list_nth_id_get
- evas_touch_point_list_nth_state_get
This also fixes a number of issues related to feeding fake
input events.
Note: I wanted to add delta x,y information as well but it's
in fact not really possible outside the event callback itself,
as the previous x,y position will not be updated unless there's
an event.
@feature
Those two properties aren't related to a "drawing" canvas
but to the current state of input.
Note: both Efl.Input.Pointer (pointer input event data) and
Efl.Input.Interface (common interface for input handling objects)
expose a pointer position API. Not sure what to do about that.
This adds support for distance, pressure, tilt and twist.
Not entirely sure if normalized & raw (x,y) should be exposed
in the eo interface. Also not sure what to do with tilt_x/y
(as used by libinput) or touch/tool width "major/minor" vs.
radius x/y.
Add debug logs in the example, including the distance.
I can't test most of these values due to a lack of compatible
hardware, but the most basic features seem to work :)
First, fixing ellipsis text positions: ellipsis items should be assigned the
text positions of the omitted text (while maintaining the formatting of the
last visual item). In the case where an entire item was rejected, it
will be assigned that item's text position. If an item was split, it will be
assigned the text position of the split portion.
The BiDi reorder code relies on properly-assigned text positions.
Second, fixing ellipsis handling: the width calc was only considering the
ellipsis item's width. However, if the ellipsis is placed as e.g. the first
visual item (such as in RTL cases), its advance value should've be considered,
instead.
Thanks Youngbok Shin for the test case and information.
@fix
After my many input events changes, a same object callback
could be called multiple times in a row because both mouse
and multi events were sent. As such, the multi event had no
direct effect (no callback called) but it reset the object's
last event type. This allowed the mouse event callbacks to be
called again.
Note that I haven't tested multi touch yet :(
Very good catch by @bu5hm4n!
Fixes T4462
Fixes T4467
Jean-Philippe Andre
Bruno Dilly
Guilherme Iscaro
Carsten Haitzler
Tom Hacohen
Stefan Schmidt
Subhransu Mohanty
Chris Michael
Marcel Hollerbach
Felipe Magno de Almeida
jiin.moon
Daniel Hirt
Sungtaek Hong
Stephen Houston
Derek Foreman
Ji-Youn Park
Cedric BAIL
Hermet Park