the normal usage of these is something like
if (!strcmp(engine, my_engine))
win = window_get(ee);
which is a waste of effort since the window_get() functions all check
the engine interface internally
When a canvas is manually rendered the ticker is just a waste of cpu, and
worse - it can wake the drm back-end from dpms sleep, as the display needs
to be awake to generate vblanks.
We fire a DBG message when attempting to start an animator in this state
because it's frequently a bug that wastes battery life - (like E doing idle
cursor animations or clock updates while the display is off)
However, dpms off is not the only potential usage of manual render, so
another commit will follow shortly to fix the bug this commit introduces -
when using a backend with a custom ticker and doing manual render with
the display on, calling ecore_evas_manual_render() will not draw with
updated animator state.
Fix T5462
Again.
Really.
Engines that provide their own tickers may need to be able to provide the
time of the last tick even if they weren't sending ticks to EFL at the
time.
This is a feature added during freeze as it's necessary to resolve a bug.
ref T5462
When using the legacy API (and in fact also with the EO API) to
listen to mouse events (move, in, out...) on a window instead
of an actual evas object, some information was missing:
- buttons (bitmask of pressed buttons)
- prev.x/y (previous position)
This is because Evas had not handled the event yet at this
point, it was coming directly from ecore_evas with incomplete
information. This patch involves evas a little bit earlier, and
also fixes evas_events_legacy.c to have consistent values for
cur/prev canvas/ouput coordinates. See also 890a91785 and
484dae76e6. Those commits were making the pointer coord
a seat-based property (instead of canvas-based) but the event
should already have those proper values before converting to
a legacy struct. This patch restores the meaning of the DUP
macros, as I observed 4 different coordinates from the app side
(instead of just 2: prev and cur).
Thanks to Andy for reporting the original issue on the ML!
If the framespace size has changed and by accident (or in fact, by
design) the evas size + framespace size is equal to the size sent
by the X server, ecore_evas_x was skipping the resize event. This
patch adds a tracking of the framespace size so that we redraw the
canvas if it changed.
This will fix issues with the main menu (since it's in the framespace,
23 pixels tall with the default theme & scale).
Note that all this is partly because the ecore evas size is the size
without the framespace, so weird calculations are made during resize...
Ref T5482
Summary:
This completes the documentation for Ecore_Evas for all (non-deprecated)
APIs.
Note that ecore_evas_software_16_ddraw_new, ecore_evas_direct3d_new,
ecore_evas_gl_glew_new, and ecore_evas_sdl16_new are left undocumented
because while they're not declared as deprecated their implementations
are either missing or marked as obsolete or legacy. I suspect a few of
the remaining routines are likely also obsolete but I added
documentation anyway.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4972
Small patch to fix misleading return value when
ecore_evas_aux_hint_val_set fails. In the above code, we will return
EINA_TRUE already if the aux_hints_set works, so this return value at
the bottom of the function should be EINA_FALSE.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to support using Ecore_Evas_Interface_Wayland in order to
add support for setting auxiliary hints on a surface
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
Revert "Revert "evas: Fix build for Windows (hopefully)""
This reverts commit c8ec1cb2af.
The two efl_input_ functions need to be declared as EOAPI inside
the file where they are implemented. Otherwise the symbols aren't
exposed and weak linking means the function call crashes.
Sorry for the first untested patch and subsequent revert. Things
should be in order now.
The declaration of some internal EO APIs was located in the wrong
library, which results on Windows to an invalid definition of
EAPI (dllexport vs dllimport).
Thanks @vtorri for the report!
Summary:
These routines all already have a @return line that states the return
values appropriately; it's unnecessary to restate the return values in
the documentation text.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4878
in some cases (e.g., the mouse-out emission from the ee wl engine),
this was calculating wrong coordinates, which would lead to a broken
chain of events like:
object mouse out -> object mouse in -> object mouse out
which would severely break some apps
@fix
Summary:
Adds a line between each function so it's more obvious what doc goes
with what API routine. Reorganize the doxygen elements so they're
consistently ordered and spaced.
No code or documentation changes; mostly just whitespace.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4866
696ed3e2e8 introduced a build failure on
macOS. _ecore_evas_subregister is being used in a foreign code module,
but it was not exported. Enforcing EAPI gives this symbol enough
visibility to be used outside of ecore_evas.