Summary:
the same as norender, but useful
Depends on D11581
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11582
Summary: this is a valid combination of parameters that should be handled
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11581
Previous vg didn't take care of cached buffers which were
allocated in it's lifetime because the cache buffers are managed
by its own cache buffer mgr, it has a limitation count of buffers also
buffers can be cleared when engine is shutdown.
This behavior is actually working properly but not well optimized
since it lost a chance to clear grown buffers.
Now vg do clear used buffers when object is invalidated.
when this lock is released, the evas may be immediately freed, leading to
invalid access in the log call
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11536
Summary:
Filter does not know how to draw native surface image using engine_data.
It means that only image knows how to draw it. In case of GL engine, image
is using a shader program for IMAGENATIVE in the common_context_image_push.
This patch makes filter work for native surface image by drawing the native
surface first using the common_context_image_push as below.
Before: image -> common_filter_*_push -> filter_output
After: image -> common_context_image_push -> filter_input ->
common_filter_*_push -> filter_output
Test Plan: {F3856981}
Reviewers: Hermet, jsuya, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11546
Summary:
modified the join enum documentation for Efl_Gfx_Join and Evas_Vg_Join
since the order of documentation is wrong
Depends on D11519
Reviewers: jsuya, Hermet
Reviewed By: jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11521
Summary:
On the SW engine, the rendering has inconsistent between smart object and
non-smart object, if they are mapped children. The smart object does ASYNC
render while the non-smart object does SYNC render. Because of this there
is a filckering rendering problem.
[Problem]
The following is a case of problems.
elm_layout (mapped, map_surface_1)
│
├─ elm_image_1 (mapped)
│
└─ elm_image_2 (not mapped)
│
└─ evas_object_image
After elm_image_1 adds draw command to the draw thread queue, and it starts
its drawing on the map_surface_1 on a thread, and stops middle of drawing.
At this point, evas_object_image does SYNC draw on the same surface
map_surface_1. And the thread for elm_image_1 works for remains.
Because the evas_object_image draws before finishing drawing of elm_image_1,
There is the problem.
F.Y.I. From the first evas_render has done SYNC render for mapped child.
cb10c7d evas: Modify software_generic ... with threaded renderer
This patch makes mapped children do ASYNC render.
Test Plan:
{F3856130}
{F3856131}
Reviewers: Hermet, jsuya, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11506
Summary:
Made small change to expand mapping range by using celling values.
Now : rgb(255,255,255) -> y(255)
Now : rgb(1 , 1 ,1 ) -> y(1)
Old : rgb(255,255,255) -> y(254)
Old : rgb(1 , 1, 1) -> y(0)
It is important for white point convert to not loss any value
Test Plan:
```
#include <stdio.h>
int main()
{
unsigned char r =255, g =255,b =255;
unsigned int gry8_old = ((r * 19595) + (g * 38469) + (b * 7471)) >> 16;
unsigned int gry8_new = ((r * 19596) + (g * 38470) + (b * 7472)) >> 16;
printf("gry_old=%i\n",gry8_old);
printf("gry_new=%i\n",gry8_new);
return 0;
}
```
Reviewers: cedric, raster, zmike, vtorri, Hermet, woohyun, bu5hm4n, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9490
Check here for a static clipper else the clipper
will move. This causes problems with very large boxes where
content will stop rendering due to the clipper moving.
Originally this wasn't meant to move but this was missed with the
API changes. It wasn't noticed as the clipper default size is
very large.
See: src/lib/evas/canvas/evas_object_smart.c.
If we exceed the 10k range content does not render due to the
move.
@fix
Summary: The x, y parameter order should be the end of efl_gfx_path_append_cubic_to()
Reviewers: Hermet, jsuya
Reviewed By: jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11491
Summary:
The glayer_tap_finger_size can get diffrent value on each profile.
Need to get system config value and will set it for gesture manager.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11485
Very complex to say, if its source object is remained as chaged state in pending object
in rendering stage, the proxy object could miss to update in the next frame because
source object won't be changed again in evas_object_change().
Thus we need to double-check if the proxy missed update or not just in the rendering.
Not clean but this is a compromised solution to not be burden for finding/checking proxies
in object trees every time.
@fix
When we do Not build with BIDI_SUPPORT, then "const Eo *eo_obj" is
never used and thus spits out an unused parameter warning during
compile. This has been bugging me for quite some time now, so put in a
small patch to silence this warning.
the previous commits introduced a abstraction for drag in drop which can
be now used for this here. With this commit all the direct protocol
handling in efl.ui is removed, and only the ecore evas API is used.
Additionally, this lead to a giant refactor of how APIs do work. All
Efl.Ui. interfaces have been removed except Efl.Ui.Selection and
Efl.Ui.Dnd, these two have been restructored.
A small list of what is new:
- In general no function pointers are used anymore. They feel very
uncompftable in bindings and in C. For us its a lot easier to just
listen to a event when a drop enters or leaves, there is no need to
register custom functions for that.
- Asynchronous data transphere is handled via futures, which proved to
be more error safe.
- Formats and actions are handled as mime types / strings.
- 0 is the default seat if you do not know what else to take.
- Content is in general passes as a content container from eina, this
also allows applications to pass custom types
The legacy dnd and cnp API is implemented based on that.
All cnp related things are in elm_cnp.c the dnd parts are in elm_dnd.c
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11190
This patch adds a small check for a valid 'obj' variable inside the
object_intercept macros, which fixes several Coverity reported issues
of NULL pointer dereference.
Fixes CID1420239 through CID1420258
when this property is set, the mixin implementation of efl_file_load() is
never called, which means the internal loaded flag (and related data) is
not set, and so the values for these properties must instead be returned
directly from the image data
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11423
this is a bit ugly, but in the case where skip_head is used it's important
to propagate the resulting Eina_File back up to the image object's data
for use in other api functions
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11422
As per mailing list discussion, This macro is apparently a forward
facing API so we should be using efl_data_scope_safe_get in the event
that the API receives an object of the wrong type (which would have
caused a crash previously).
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11450
Small patch to reduce the number of calls to efl_data_scope_get as per
mailing list discussion. Since the
EVAS_OBJECT_INTERCEPT_CALLBACK_DEFINE macro already retrieves the
protected data via efl_data_scope_get, we can just pass that
protected data directly to evas_object_intercept_init/deinit functions
without the need to refetch it.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11449
Summary:
Legacy event info have canvas and output coordinates.
Output coordinates have information of original position.
Canvas coordinates have information of transformed position.
So keep backward compatibility, fix filling legacy information.
This reverts commit 7f724f6c5d
Reviewers: Hermet, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11445
need to always make sure we set this when a gesture is being tracked so
we know which touch point we're watching
Differential Revision: https://phab.enlightenment.org/D11387
it's not enough to just check the value for this in the recognizer; we need to
always modify the recognizer property here to correctly manage object lifetimes
and generate the correct events (e.g., not emitting momentum gestures while
multiple fingers are moving simultaneously)
also update a couple existing unit test checks which were wrong
Differential Revision: https://phab.enlightenment.org/D11386
if the recognizer is processing using a touch point other than the first finger,
e.g., in the case where multiple fingers are pressed simultaneously, then
the recognizer needs to also detect distance based on that finger
more fixes for triggering tap events while fingers are moving
Differential Revision: https://phab.enlightenment.org/D11385
when a gesture ends and is not set to continue, the gesture object must
be preserved until the entire touch sequence ends in order to ensure that
all the touch point states are accurately detected and updated and so
additional instances of that gesture are not accidentally triggered
this fixes weird corner cases where you could tap with two fingers and
then get a long press event while dragging the second finger around as
long as you did it quickly enough
Differential Revision: https://phab.enlightenment.org/D11384
this is a 1:1 port with minimal changes other than what's necessary to
integrate into the new framework
Differential Revision: https://phab.enlightenment.org/D11383
this is consistent with the rest of efl naming
ref T8503
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D11376