it might be possible the pointer is outside the screen areas and
perhaps gets caught there, so move the pointer in first before setting
up new barriers
@fix
setting a loop time timestamp in the future will lead to all sorts of
bad things. the idea is it was meant to go back a little in time AFTER
some sync/animation etc. event to pretend to be at the time when that
event happend (it just took some time ot arrive at the process) and so
animation and other timelines all agree to be at this time a little
bit in the past. going forwards leads to bad things so disallow it and
complain. this fixes weston in a window problems when it sends
timestamps in the future from weston...
@fix
yes - time went backwards. we get time from the device driver and
vsync events... this is so incredibly wrong ... it should not have
ever happened... but it did and that caused all sorts of bad things to
happen to animators. this guards against that and tries to get the
system clock time and if that doesnt work it just takes last time +
0.901.
@fix
while it requires an extra wakeup from vsync thread -> e and this adds
a bit of jitter, it's mroe reliable in the face of "missed a frame"
timings and doesnt degrade as badly.
libraries are split into deps, external deps, and pub deps.
Evas engines are refactored to use the predefined engine deps.
this is preparation work for efl-one.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11806
These meson files did not have the c_args handling before. Make sure we
use package_c_args here as well.
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11860
after i noticed some jitters, it seesms one thread to listen for vsync
events then to wake up the mainloop can suffer from irregular
scheduling jitters. it seems to be highly depenedent on both gpu
driver and cpu but it seemed the vsync thread itself was more reliably
woken than the mainlooop it then signalled, so merging this back is
just batter. it's configurable via an environment variable so we can
try either right now and see, but default is now to be in main loop.
i dont know why we skipped the first two atoms, but right now, if a
application is only providing one single target, we would crash.
With this we might copy a few atoms more. However, these atoms do not
matter, as we skip those, that we cannot understand
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11194
we need that in order to get seleciton per window events, which is
required to get a nice mapping onto the ecore_evas object.
Reviewed-by: Carsten Haitzler (Rasterman) <rasterman.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11193
xserver stopped containing mouse to screen bounds a while back... this
si broken. so enforce this policy with an api that take a list of
screen rects (relative to root) and makes those the barrier bounds so
that mouse doesn't go out of the screen anymore. new api to enable
this fix in e.
Summary:
This was a X11 extension mainly developed for Tizen. By now I can only
find it packaged by Gentoo as the only Linux distribution and Tizen is
now longer using it either. Bringing it up during EDD and on the mailing
list did not come up with any users.
I think we can go ahead and deprecate the API and remove the
functionality.
Reviewers: raster, cedric, devilhorns, zmike
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10823
add some infra to be able to get and set device properties (as well
as know if devices changed to we can refersh a gui or re-apply saved
settings etc.). it doesn't do everything but... it adds enough to
build on in e.
Summary:
block calls to XSelectInput with the root window if the root window is
currently being "managed" in-process in order to avoid breaking the
running wm
Depends on D10013
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10014
Summary:
this is just a shortcut for watching properties in the case where no wm is
active in the process
Depends on D10012
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10013
Summary:
when ecore_x_window_manage is called, this is probably only for the case of
managing the root window, i.e., running a window manager. store this state
internally so that we can avoid calling additional XSelectInput later and
fucking up the expected eventing
Depends on D9899
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10012
Summary:
this handles the case of reinitializing a component, but it's totally
broken in the case of doing a full ecore restart
Depends on D9253
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9254
so i've been wondering what is going on for a few days... and i've
figured it out finally... my mouse seems ot like to generate 1000
events per second. not your usual 100 or 200. it only happened on this
one machine so i was wondering what on earth was up. this machine was
different in other ways like an arm cpu, differing gpu (rx550),
different distro and so on. this is creating a storm of motion events..
and this is causing all sorts of overhead in just trying to deal with
them all like generate more internal events, emit signals for every
one of them and so on. there is no attempt to play catch-up or
anything - just build up a bigger and bigger queue of them to deal
with. this is NOT GOOD. this restores our old commented out event
skipper that got commented out during some xcb work actually -
not on its own. it was a huge xcb patch that commented it out.
this restores it and makes it a little cleaner with a bool and now the
perf issues i was seeing are gone. this is such a major performance
fix that this deserves a backport.
@fix @optimize
Summary:
meson and autotools were a bit out of sync with this, resulting in
unexpected behavior
Reviewers: billiob
Reviewed By: billiob
Subscribers: billiob, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8641
A New entry is added to _ecore_key_grabs even when no key was grabbed.
Summary: The key grab and ungrab functions should return which keycode was used. Proposed by pascal@ordissimo.com
Reviewers: zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7923
This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
it was a lot of if cases before now it's an array with min version
parameters and globs for matching drivers etc. - much cleaner and
neater to afdd things to the whtielist now.
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Carsten Haitzler
Vincent Torri
Alastair Poole
Elyes HAOUAS
Marcel Hollerbach
Stefan Schmidt
rafspiny
Mike Blumenkrantz
Xavi Artigas
Thierry
Marcel Hollerbach
Mike Blumenkrantz