Summary:
This is a fix to one of the FIXME in the code, evas_object_textblock.c
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: herdsman, tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1383
Local and base class functions are supported.
When @empty is provided, dummy functions (initializing the parameters with default
values if needed) are generated.
When @auto is provided on properties, access to internal data variables is done. On
set, it will assign parameters values to private data members. On get,
parameters are set with private data members values.
See the supplied tests as examples.
@feature
This is a critical performance issue that was introduced during our move
to eo2. This code was still eo1 style so I guess it was just forgotten.
The result is that canvas with large numbers of widget were slower after
the migration.
@fix
before trying to use it
eo_data_scope_get Could return NULL if it does not find valid
ecore_timer_data on this object. We should check that return before
just Assuming that timer data is valid.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Now they're registered correctly. Also, add new API, eolian_implement_is_virtual.
Also, deal with get/set properly (when filling in additional implements)
Summary:
evas_font_dir_cache_free() is called twice in evas_shutdown().
evas_common_shutdown() will call evas_font_dir_cache_free().
Test Plan: NONE
Reviewers: tasn, woohyun
Subscribers: herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D1417
eina_tls_get is really slow, having a fast path for the main loop does really
help us right now. It is also unlikely that slowing down a little bit the use
of eo in thread is going to have any impact on application speed any time soon.
I win a +10% on expedite benchmark compared to without.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This fixes an issue where we had to hard-code the resolution in the
wl_drm module. Instead, we now properly get the current screen
resolution/mode from the drm library and use that.
NB: This is needed to fix wl_drm module in Enlightenment to setup the
proper resolution.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This adds the ecore_evas function pointer for
ecore_evas_screen_geometry_get. This will be used from the drm
compositor to return the current screen geometry.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This adds an API function that we can call to return the screen
geometry. This will be used from ecore_evas to get the screen_geometry.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As the implements list will soon contain all methods and properties,
do some preparations. The Eolian library now fills in class field in
implements early on when the implement is local. The Eolian C generator
now checks for local implements and skips them (so that things don't break).
Summary:
Now, evas gl-drm engine is using ecore_drm instead of its own code to handle tty.
This patch has removed obsolete tty handling codes from engine. It is almost the same as what
Stefan Schmidt did to evas drm engine.
Test Plan: N/A
Reviewers: devilhorns, cedric, raster, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1409
Summary:
No need to check tty fd again as we just did that.
Remove this and adjust indent.
Test Plan: N/A
Reviewers: devilhorns, stefan_schmidt, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1407
Summary:
Add code to generate edc source for all transition types used in program block.
_edje_generate_source_of_program() api generates program source code from the edje object.
Very few transition types are handled in the function. Added code to generate edc source
code for all the transition types.
Reviewers: govi, raster, jpeg, zmike, cedric
@feature
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1367
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: Get rid of the old NSApplicationLoad() which was aimed to be use with Carbon. Unless the NSRunLoop is strictly integrated to the ecore_main_loop() (where cocoa events would be checked when entering the ecore_main_loop) I think the poller is the only option left.
Reviewers: raster, naguirre, raoulh, stefan_schmidt, cedric
@feature
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1222
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>