| Summary: | Plasma stops responding after some operations | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Roman S. <romanujan> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Roman S.
2008-01-12 18:12:27 UTC
Then don't do it. ;) Plasma hasn't stopped responding. It's just spending a lot of time painting an svg at a huge size, which is exactly what you told it to do. Possibly. But I have seen a dialog box telling me that it stopped responding (I would atach a screenshot here, but was unable to make it). The desktop got nearly completely stuck, mouse cursor was moving in large steps every few seconds, I was unable to click anything - even close the CPU-eating widget. It seems to me something is REALLY wrong with task priorities, or maybe priorities of some operations in a single task. I think that if no other solution is possible, then at least some failsafe mechanism should be implemented to protect the widget closing buttons. Look at this from the point of view of an avarage user - "I have just resized the widget, and Linux suddenly got completely stuck". Widgets are not separate processes so everything in plasma has to wait if one uses a lot of CPU. There's not really anything that can be done about that. Given the dimensions of your screen, you resized a rotated clock to about 3300x3300. That's a whole lot of calculation. After a while the painting would have finished, after which you would have been able to close it normally. > There's not really anything that can be done about that. Maybe threading would/could help there to don't block? At least http://doc.trolltech.com/main-snapshot/threads.html#threads-and-the-svg-module says that "QSvgGenerator and QSvgRenderer classes in the QtSvg module are reentrant". Though I guess this has very low priority since the only use-case for it are imho situations like this + it would make debugging much more difficult and may therefore also a question of advantage vs. disadvantage. > Widgets are not separate processes so everything in plasma has to wait if one uses a lot of CPU. There's not really anything that can be done about that.
I'm not sure if I understand - in KDE 4 a single plasmoid can take down the whole desktop??? One infinite loop in Python code and... a complete stuck? Maybe there could be some way to stop it if it takes too long to redraw, or something... Otherwise, there will be a lot of problems with buggy widgets :(
yes, shocking: bad code can disrupt an application! horror! and yes, asking it to do something as stunningly silly as render a complex svg at 1050*1050 and rotate the results will result it things being a bit slow. i'll bet it's actually running out of pixmap cache and so having to re-render constantly on every repaint. as for threaded painting, there's a set of patches floating around for that. they didn't make it for 4.0 and i hope the author has time to come back to them for 4.1. > yes, shocking: bad code can disrupt an application! horror! Maybe... But more and more applications tries to run plugins in separate processes, to avoid crashes. Look here: http://zrusin.blogspot.com/2007/05/browser-plugins.html http://amarok.kde.org/blog/archives/76-Inside-amaroK-1.4-Collection-Scanner.html I'm not sure, but if I remember correctly the Firefox guys consider doing the same, so that a bug in Adobe Flash Player or Acrobat Reader won't crash the whole browser (I cannot find this info right now). The more easy writing plasmoids is, the more unskilled developers will code their own widgets, and since Plasma desktop is a very important application... I hope you will at least consider similar solution. A pitty I cannot convert this bug report into a wish - it seems more appropriate now. > as for threaded painting, there's a set of patches floating around for that. > they didn't make it for 4.0 and i hope the author has time to come back to > them for 4.1. That would be great, this would probably solve the issue :D And since 32-core CPUs will eventually find a way to our desktops... I guess from my point of view this is the end-of-topic. I have reported the problem, you don't need my help with reproducing it, I have explained my point of view - so THE END :) > more and more applications tries to run plugins in separate processes you're comparing apples (web browser plugins delivering content) to oranges (a seamless, interacting desktop scene). amarok's out of process scanner is also something completely different. besides the obvious graphical and interaction issues, you may also wish to consider the overhead of running each applet as its own process. not pretty. > the more unskilled developers will code their own widgets two things: a) you don't need to run random bits of code b) that's why we are encouraging them to use languages we can manage at runtime more effectively. eventually it will probably be necessary to build sandboxes around the scripting support for both feature and resource acccess. |