| XWidgetSoft Forum https://bbs.xwidget.com/ |
|
| Feature Request: Xwidget Stability Improvement https://bbs.xwidget.com/viewtopic.php?f=3&t=6735 |
Page 1 of 1 |
| Author: | yereverluvinuncleber [ June 21st, 2017, 4:41 am ] |
| Post subject: | Feature Request: Xwidget Stability Improvement |
As all the Xwidgets run within the context of the same process, high cpu usage in one widget can cause a drastic slow-down in all the others. When the host o/s dynamically lowers the priority of the xwidget process (a normal thing to do in a time-sharing system), all the widgets will appear to pause/hang for a period until the CPU contention is resolved in Xwidget's favour. In comparison, due to its architecture and the way each yahoo widget runs in its own process, the yahoo widget engine is much more stable and if a widget ever does crash, it doesn't take all the other widgets with it. If a yahoo widget consumes too much cpu, other widgets will only be affected in the way that all processes will be affected, they won't instantly freeze or appear to hang. The negative side is that each independent yahoo widget consumes more resources than an Xwidget. However, if you have a powerful and modern PC with a decent processor and plenty of memory (most do these days) the amount of resources that these widgets consume is really quite trivial on a modern quad core 3+ghz system. The system I am using now is an old core2duo, 2.5ghz machine and the load of running the xwidget and yahoo widget engines simultaneously with 20 or so widgets is low if not negligible. Due to the way that all Xwidgets run within the same context, I find the stability of the Xwidget engine is questionable, especially when developing a new widget and running multiple other xwidgets simultaneously. When running highly animated gauges, the dock can become paralysed and sometimes your widgets refuse to initialise. Killing Xwidgets altogether seems to be the only solution. It is actually useful having a Yahoo widget that is designed (a big kill switch) to actually kill and restart Xwidgets and vice versa! An architectural change is required within Xwidgets that allows the widgets to be run independently within their own process. This would bring stability to Xwidget. |
|
| Author: | yereverluvinuncleber [ July 7th, 2017, 1:07 am ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
The editor and the debugger run within their own processes distinct from the standard xwidget process. Therefore you can kill xwidgets and find that the IDE and the xwidget you are debugging is still running on your desktop. This isn't a bug. It shows that widgets can be run within their own process. This is already part of xwidget. There needs to be a way of configuring xwidgets to allow all widgets to operate in the same fashion. Each widget running within its own process. |
|
| Author: | yereverluvinuncleber [ October 2nd, 2017, 12:23 am ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
Individual processes per widget is an essential function for Xwidget to operate in a stable fashion. During system startup if xwidget is set to autorun, then Xwidget has to compete for cpu with other processes. Occasionally, one or more of the widgets will refuse to initialise and Xwidget does not quite complete its own startup due to all the processes (including the stalled process) running within the same context. An xwidget restart is then required to sort out the stalled startup. If each widget had its own process then one widget stalling would have no effect on the rest of the engine. The good thing about having pre-existing competitive widget engines is that many of the architectural design issues have already been determined so all any potential widget engine dev has to do is - to do what those engines have already done. Look to the yahoo widget engine and see what it does well, copy that. |
|
| Author: | yereverluvinuncleber [ October 3rd, 2017, 4:56 am ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
Whenever Xwidget has an instability then it affects all other widgets. This is an architectural mistake. One widget looping/stalling should NEVER affect other widgets. In other more mature engines, if one widget has an issue then you can simply kill the rogue widget. Suggestion: If the engine is ever modified to allow running one process per widget then the process name should consist of the widget name + xwidget.exe ie. mediaPlayerXwidget.exe this allows identification of the offending widget in task manager meaning that it can be easily identified and shutdown. |
|
| Author: | yereverluvinuncleber [ November 4th, 2017, 8:09 am ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
A side effect of this 'feature' is definitely is a bug that results in unwanted behaviour... Some of my widgets fail to respond over time, namely the network i/o gauges. The cores seem to stop returning the information to the widget periodically. To get round this I have a timer set on the widget so that if the widget fails to register any i/o for a set period of time it reloads itself, or restarts. When the widget restarts ALL the widgets come to the fore in front of any application that is running. This is due to the fact that all widgets are connected and run within the same process space. As the restarted widget initiates it comes to the fore bringing all the other widgets with it. This is unwanted behaviour. For several good reasons each widget should be able to run in its own process. Any process function or malfunction would not adversely affect another running widget. The way the Xwidget currently operates could be seen as one big bug, at best a feature with unpleasant side-effects. We need the option to run one widget per process (as per the widgets being edited) or as it is today. |
|
| Author: | yereverluvinuncleber [ February 12th, 2018, 12:35 pm ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
There is another unwanted side effect of the Xwidget monolithic design, that is the effect on Xwidget when the Xwidget process is swapped out. When memory is short and lots of applications are being run then the demand on memory is high, the o/s may then swap out a process to the swapfile. If this occurs to the Xwidget engine then the swap back in time is extended and can result in unresponsive widgets until the whole engine is returned to working memory. If each widget was within its own process space then individual widgets could be swapped out by the o/s and swap back in time would be much smaller. The impact of swapping out a single widget would be trivial. Having each process swappable is a boon to the o/s as it means it can swap widgets in and out as it see fit. Xwidget, being such a monolithic program containing all widgets can only be swapped out at extreme times and maybe not at all reducing the o/s ability to control system memory resources. |
|
| Author: | yereverluvinuncleber [ March 25th, 2018, 1:59 am ] |
| Post subject: | Re: Feature Request: Xwidget Stability Improvement |
Another reason for comparing the Yahoo widget versions with the Xwidgets is to demonstrate how efficient the YWE animations are when running as separate processes. When I am running 6 or 7 Xwidget gauges on the desktop with pointer animations turned on then there is a definite decrease in the desktop redraw response times, you can observe white shadows behind the desktop windows as you drag them. This does not occur using YWE animations and you can have multiple gauges on screen with no adverse effect. I think this has to do with the monolithic nature of xwidgets all running in the same process, the effect of screen redraw on the Xwidget 'layer' has to compete for cpu cycles with running widgets leaving a slight lag that causes the white undrawn 'shadows'. Tony should compare the two engines and look to improving that part of Xwidget. |
|
| Page 1 of 1 | All times are UTC - 8 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|