Page MenuHomePhabricator

tests/elm: speed up all main loop timer execution

Authored by zmike on Aug 8 2018, 12:11 PM.



this spins a second loop which manages a timer to trigger the canvas tick
and increase the loop timer by a fixed interval on every timer call

by increasing the loop time manually, timers such as edje animation timers
which would usually take a very long time (e.g., 0.5s) to run will instead
complete almost instantly, making tests run much faster

the second loop is necessary in this case in order to accurately provide ticks
at a consistent interval without any modifications to timing
Depends on D6766

Diff Detail

rEFL core/efl
Lint Skipped
Unit Tests Skipped
Build Status
Buildable 9330
zmike created this revision.Aug 8 2018, 12:11 PM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added:

zmike requested review of this revision.Aug 8 2018, 12:11 PM

Could this be done with an awful custom ticker instead?

14 ↗(On Diff #16218)

Is this newline here on purpose?

152 ↗(On Diff #16218)

I'm lazily trying to recall how this works without reading the code. ;)

Won't loop time get set again by the system clock on the next main loop iteration?

Feels like we'll see some non-monotonic clock wackiness here?


That's just nasty - why can't we just change all the call sites to call timer_add?

zmike added inline comments.Aug 8 2018, 12:51 PM
14 ↗(On Diff #16218)

Yes, it's a crucial newline.

152 ↗(On Diff #16218)

See D6764


I want to avoid making it more difficult to add unit tests.

raster requested changes to this revision.Aug 8 2018, 9:07 PM
raster added a subscriber: raster.

this is asking for trouble. creating another loop and expecting to be able to iterate it and run it as normal is bound to end in tears at some point. it is not intended or designed to work like this. the loop class is intended for one thing - to be created as a bi product of ecore's init (as a parent class) and driven from there. something in future is going to break this and do so validly.

if your intent is to "speed up time" artificially i'd look at ecore and modify ecore_time_get) to multiply this by some factor and then divide the next sleep timeout in select by the same factor to sleep for a lesser amount and maybe use an env var to do this like ECORE_TIMELINE_MULTIPLIER or something...then just set the env var for any test being run and time will move faster for that process as a whole... its probably less code than this patch and going to be more generally useful and reliable.

This revision now requires changes to proceed.Aug 8 2018, 9:07 PM
zmike added a comment.Aug 9 2018, 10:04 AM

This is an interesting proposal, so I've created D6806 to evaluate the versions side-by-side.

ManMower accepted this revision.Feb 1 2019, 12:08 PM
This revision was not accepted when it landed; it landed in state Needs Review.Feb 1 2019, 12:11 PM
This revision was automatically updated to reflect the committed changes.