[EGIT] [website/www-content] master 01/01: Wiki page mainloop changed with summary [] by Raster
WWW-www.enlightenment.org pushed a commit to branch master. http://git.enlightenment.org/website/www-content.git/commit/?id=96b2a6f7e513264db15d19e439f12bea8c7f1d86 commit 96b2a6f7e513264db15d19e439f12bea8c7f1d86 Author: Raster Date: Thu Apr 30 01:34:49 2015 -0700 Wiki page mainloop changed with summary [] by Raster --- pages/docs/efl/mainloop.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/pages/docs/efl/mainloop.txt b/pages/docs/efl/mainloop.txt index 9c91fea..2fb1d03 100644 --- a/pages/docs/efl/mainloop.txt +++ b/pages/docs/efl/mainloop.txt @@ -77,4 +77,8 @@ EFL likes to defer work as long as possible to avoid doing it multiple times. th As a result of calculating and implementing such calculations, it can happen that you may add jobs, which will be processed now after going idle. If you post events or jobs here, then the mainloop will go idle and immediately wake up (not calling any idlers as it spends no time sleeping due to pending events). Also actual UI events may be called here due to changing of object states, so be aware that this can happen early during entering idle, before rendering begins. -Rendering may render inline in the mainloop or may farm off rendering to threads to do in parallel, depending on the engine being used. This may change over time, but in the long-run we aim to move more and more of our rendering off into many slave threads to free up the mainloop as much as possible. \ No newline at end of file +Rendering may render inline in the mainloop or may farm off rendering to threads to do in parallel, depending on the engine being used. This may change over time, but in the long-run we aim to move more and more of our rendering off into many slave threads to free up the mainloop as much as possible. + + + +~~DISCUSSIONS~~ \ No newline at end of file --
[EGIT] [website/www-content] master 01/01: Wiki page mainloop changed with summary [] by Raster
WWW-www.enlightenment.org pushed a commit to branch master. http://git.enlightenment.org/website/www-content.git/commit/?id=aee1bab093d4c8ae28618c460f2dcff90a6f478a commit aee1bab093d4c8ae28618c460f2dcff90a6f478a Author: Raster Date: Mon Apr 27 23:35:55 2015 -0700 Wiki page mainloop changed with summary [] by Raster --- pages/docs/efl/mainloop.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pages/docs/efl/mainloop.txt b/pages/docs/efl/mainloop.txt index e7009cf..8c64e75 100644 --- a/pages/docs/efl/mainloop.txt +++ b/pages/docs/efl/mainloop.txt @@ -16,9 +16,9 @@ The mainloop will sit and iterate forever until something flags it to stop. This |**[[#Wake Up]]** | This is a special timepoint and it is stored and can be retrieved with ecore_loop_time_get() | | |**[[#Idle Exit]]** |Coming out of the idle state due to a timeout or I/O event |[[ecore_idle_exiters]] all called here, if registered| |**[[#FD Event handling]]** |File Descriptors (fd's) are processed here (read from or written to) and events queued |[[ecore_fd_handlers]] callbacks called here (read, write, buffer) | -|**[[#Event filtering]]** |Filter out events we don't want now that we have gathered all pending I/O | [[ecore_event_filters]] callbacks called here | -|**[[#Event handling]]** |Regular event handling (in order) and events may still be generated and added to the queue as a result of event handling via ecore_event_add() or ecore_job_add() for example |[[ecore_event_handlers]] callbacks called here as well as [[ecore_timers]] callbacks, [[ecore_animators]] callbacks for animation, [[ecore_jobs]] callbacks, and almost all the UI callbacks (such as mouse click events, enter/leave, key events, other widget changes etc.) | -|**[[#Entering idle]]** |The mainloop is about to go idle again now that everything has been processed | [[ecore_idle_enterers]] are called here (the first of which may be the [[evas_rendering]] related callbacks which will calculate widget and object changes, actually trigger rendering etc., depending on the order of idlers added via ecore_idle_enterer_add() to the end of the idle enterer queue or ecore_idle_enterer_before_add() which adds to the start of the idle enterer queue | +|**[[#Event Filtering]]** |Filter out events we don't want now that we have gathered all pending I/O | [[ecore_event_filters]] callbacks called here | +|**[[#Event Handling]]** |Regular event handling (in order) and events may still be generated and added to the queue as a result of event handling via ecore_event_add() or ecore_job_add() for example |[[ecore_event_handlers]] callbacks called here as well as [[ecore_timers]] callbacks, [[ecore_animators]] callbacks for animation, [[ecore_jobs]] callbacks, and almost all the UI callbacks (such as mouse click events, enter/leave, key events, other widget changes etc.) | +|**[[#Entering Idle]]** |The mainloop is about to go idle again now that everything has been processed | [[ecore_idle_enterers]] are called here (the first of which may be the [[evas_rendering]] related callbacks which will calculate widget and object changes, actually trigger rendering etc., depending on the order of idlers added via ecore_idle_enterer_add() to the end of the idle enterer queue or ecore_idle_enterer_before_add() which adds to the start of the idle enterer queue | |REPEAT |Go back to the top of this table and repeat | | == Idle == --
[EGIT] [website/www-content] master 01/01: Wiki page mainloop changed with summary [] by Raster
WWW-www.enlightenment.org pushed a commit to branch master. http://git.enlightenment.org/website/www-content.git/commit/?id=6d83f11b1f3a506d99d9cc31d411cf777424b726 commit 6d83f11b1f3a506d99d9cc31d411cf777424b726 Author: Raster Date: Fri Apr 24 19:09:59 2015 -0700 Wiki page mainloop changed with summary [] by Raster --- pages/docs/efl/mainloop.txt | 50 - 1 file changed, 45 insertions(+), 5 deletions(-) diff --git a/pages/docs/efl/mainloop.txt b/pages/docs/efl/mainloop.txt index 95ab7fa..e7009cf 100644 --- a/pages/docs/efl/mainloop.txt +++ b/pages/docs/efl/mainloop.txt @@ -13,7 +13,7 @@ The mainloop will sit and iterate forever until something flags it to stop. This ^Stage ^Description ^Callbacks called^ |[[#Idle]] |Totally asleep waiting on timeouts or I/O UNLESS idlers are registered | [[ecore_idlers]] are called in a tight loop, one after the other during this time | -|**[[#Wakeup]]** | This is a special timepoint and it is stored and can be retrieved with ecore_loop_time_get() | | +|**[[#Wake Up]]** | This is a special timepoint and it is stored and can be retrieved with ecore_loop_time_get() | | |**[[#Idle Exit]]** |Coming out of the idle state due to a timeout or I/O event |[[ecore_idle_exiters]] all called here, if registered| |**[[#FD Event handling]]** |File Descriptors (fd's) are processed here (read from or written to) and events queued |[[ecore_fd_handlers]] callbacks called here (read, write, buffer) | |**[[#Event filtering]]** |Filter out events we don't want now that we have gathered all pending I/O | [[ecore_event_filters]] callbacks called here | @@ -23,18 +23,58 @@ The mainloop will sit and iterate forever until something flags it to stop. This == Idle == -Most applications spend the vast majority of their lives being idle. They are waiting on something. On input from the user. On data from a network to arrive. It is rare that applications are continually processing. Often they want to process in quick batches to get an update to the user as soon as possible then go back to sleep. Sometimes they do have specific processing needs, and those might impact the mainloop if executed directly in-line. EFL Has support for various ways of [[threads [...] +Most applications spend the vast majority of their lives being idle. They are waiting on something. On input from the user. On data from a network to arrive. It is rare that applications are continually processing. Often they want to process in quick batches to get an update to the user as soon as possible then go back to sleep. -Developers can [[ecore_idlers|register callbacks]] to be called whilst sleeping in idle, instead of actually sleeping. This would be pretty poor behavior to use often and is highly discouraged. It is a very rare day that you need this. If you find yourself using idlers, chances are you are "doing it wrong". Re-think what you are doing. If you must register an idler, ensure you delete it as soon as it is no longer needed, and that an idler starts and finishes as rapidly as possible so it [...] +Sometimes they do have specific processing needs, and those might impact the mainloop if executed directly in-line. EFL Has support for various ways of [[threads|interacting and managing threads]], and highly encourages clear separation of tasks, rather than mixing control of an application state between many threads. -== Wakeup == +EFL pushes you to a design where you isolate work on something heavy inside of a thread, and once that work is ready to be seen, the mainloop is informed and does the appropriate state/UI etc. changes to make that happen. These threads may continue to process while the mainloop is idle, or whilst it is busy. + +Developers can [[ecore_idlers|register callbacks]] with ecore_ilder_add() to be called whilst sleeping in idle, instead of actually sleeping. This would be pretty poor behavior to use often and is highly discouraged. It is a very rare day that you need this. If you find yourself using idlers, chances are you are "doing it wrong" and re-think what you are doing. + +If you must register an idler, ensure you delete it as soon as it is no longer needed, and that an idler callback itself starts and finishes as rapidly as possible so it does not affect the time it takes to wake up from idle too badly. + +Of course setting up such idlers will result in users seeing "high CPU usage" and complaining, so stay clear of them whenever possible. + +== Wake Up == + +When a process wakes up from idle is a special time in its life. The mainloop records this time-point and it can be queried with ecore_loop_time_get(). This will return the "logical" wake-up time as a time-point (since some point in the past) in seconds. As this function returns a double, there is plenty of precision for sub-second accuracy. The zero time is system dependent, but it likely will be something like the time when the sy
[EGIT] [website/www-content] master 01/01: Wiki page mainloop changed with summary [] by Raster
WWW-www.enlightenment.org pushed a commit to branch master.
http://git.enlightenment.org/website/www-content.git/commit/?id=c67c2f9b4f29be9100dcc5b4308cacdc3cce3ff4
commit c67c2f9b4f29be9100dcc5b4308cacdc3cce3ff4
Author: Raster
Date: Fri Apr 24 18:29:30 2015 -0700
Wiki page mainloop changed with summary [] by Raster
---
pages/docs/efl/mainloop.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pages/docs/efl/mainloop.txt b/pages/docs/efl/mainloop.txt
index b9dd016..95ab7fa 100644
--- a/pages/docs/efl/mainloop.txt
+++ b/pages/docs/efl/mainloop.txt
@@ -1,4 +1,4 @@
-+-**~~Title: EFL Mainloop~~
+~~Title: EFL Mainloop~~
~~CODE-c~~
{{page>index}}
--
