[Spread] A continuously growing number of dead applications in the spread use more and more memory
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Ubuntu UX |
Fix Committed
|
High
|
Vesa Rautiainen | ||
| unity8 (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
What should we do when there's a large number of dead applications (automatically killed due to out-of-memory situations) in the spread?
Option 1 - Keep them all in the spread
We must them unload those app screenshots (move them to disk) to save memory. If the user has a lot of dead apps in the spread, even though the apps themselves are not taking up memory space anymore, their respective screenshots in the spread still do.
So oldest of those dead apps that are not being displayed on the spread should have their screenshot images unloaded and saved to disk. If the user then scrolls the spread making them visible again they should be loaded back from disk.
There's the risk that if the user is flicking too fast down to the oldest apps, he might see screenshots popping in as they're reloaded from disk.
Option 2 - Automatically remove the oldest dead ones
Simpler to implement and there's no risk of running into the "texture pop in" situation described above.
It also save the user the burden of manually removing apps he doesn't care anymore and probably forgot about long ago.
-------
Desired solution:
Option 1 with upper limit value 100. See the reasoning from comment section below.
| kevin gunn (kgunn72) wrote | #1 |
| Changed in ubuntu-ux: | |
| assignee: | nobody → Vesa Rautiainen (vesar) |
| summary: |
- A continuously growing number of dead applications in the spread use - more and more memory + [Spread] A continuously growing number of dead applications in the + spread use more and more memory |
| Changed in ubuntu-ux: | |
| importance: | Undecided → High |
| status: | New → Triaged |
| no longer affects: | unity8 |
| Vesa Rautiainen (vesar) wrote | #2 |
| description: | updated |
| Changed in ubuntu-ux: | |
| status: | Triaged → Fix Committed |
| Florian Boucault (fboucault) wrote | #3 |
| Daniel d'Andrada (dandrader) wrote | #4 |
| Florian Boucault (fboucault) wrote | #5 |
Option2 does make sense to me as a viable option. However, I would think we'd want some bare minimum. Meaning we can't really control when out of memory will hit....my hit at the 40th open app or it might hit on the 4th...I would think there's probably some raw number we'd want to target like....10 apps in history...so that, we might end up with a hybrid approach. hope that makes sense.