| |||||||||||||
What have really changed?What have really changed?Posted Dec 16, 2011 19:23 UTC (Fri) by khim (subscriber, #9252)In reply to: 2011: The Year of Linux Disappointments (Datamation) by fuhchee Parent article: 2011: The Year of Linux Disappointments (Datamation)
This checkpoint/restore stuff is so PalmOS; it's surprising that a decade+ later, with 100x the hardware resources, it's still considered necessary/appropriate. It's not surprising at all. Hardware may be 1000x more powerful (you mussed one order of magnitude), but system requirements grew 1000x, too. Think about it: Pilot 5000 had 512K of memory and 160x160x1bpp screen. Full system memory was large enough to keep contents of about 163 screens. "Latest and greatest" uber-powerful Galaxy Nexus has 1GB of memory and 1280*720*24bpp screen. Full system memory is large enough to keep about 388 screens. This means that, relatively speaking, hardware resources are about 2-3 times more powerful then they were back then. So... why exactly do you expect radically increased capabilities WRT multitasking? AFAIK N900 is extremely painful to use exactly because it tries to use "true multitasking" on the hardware which is just not powerful enough.
(Log in to post comments)
What have really changed? Posted Dec 16, 2011 19:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"Full system memory [was 163 and now ] is large enough to keep about 388 screens."
That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:20 UTC (Fri) by khim (subscriber, #9252) [Link] That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state. Sorry, but this exactly what they do. Of course it's not 100% apples-to-apples comparison, but it's pretty close to it. Where you see some savings you immediately see more "bloat" applied. For example where Palm used bitmap fonts while Android uses vector fonts so difference should be much smaller then 1000x, right? Nope: Palm used 8bit encoding with tiny number of glyphs while Android supports large subset of Unicode. Note that these fonts must be rasterized which needs memory for caching, etc. Amount of resources needed to produce 2D graphic correlates with the number pixels on your screen pretty damn well. Yes, there are different techniques involved which may push the balance one way or another but the raw amount of data on your screen is still very good starting point.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
I'm sorry, I don't see how the plus.google.com post substantiates that the *application context that needs to be saved/restored* during an app switch is somehow proportional to the graphics frame buffer size. Can you help me out a more sketched-out example?
Sorry, my bad... Posted Dec 17, 2011 9:21 UTC (Sat) by khim (subscriber, #9252) [Link] I've missed one logical step because I was sure your understand that your correct fact (applications don't save state in such proportion to their window state) damns your idea, not mine :) Sorry about that. Obviously applications don't save state in such proportion to their window state when they are doing checkpoint/restore stuff using application-specific code. Yet they do if they use generic code! Working set of typical application includes quite a few buffers which size is directly proportional to the size of screen. If you don't ask application to checkpoint/restore stuff using application-specific code then you need to save/restore these buffers, too. And since you can fit about about the same number of them in memory on PalmOS and on Android... the same principle applies.
Sorry, my bad... Posted Dec 17, 2011 10:55 UTC (Sat) by yoush (subscriber, #38940) [Link]
> If you don't ask application to checkpoint/restore stuff using
> application-specific code then you need to save/restore these buffers...
For last ~20 years, exposure events have been used to avoid framebuffer saving.
Sorry, my bad... Posted Dec 17, 2011 14:58 UTC (Sat) by pboddie (subscriber, #50784) [Link]
Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Twenty years ago, it just wasn't possible to have all the applications caching their window contents in memory, although I do accept that caching rendered font bitmaps is very beneficial for performance even in memory-constrained systems: I remember increasing the font cache above the default 48K on my 1MB machine to get substantially faster text rendering.
PCs and phones are fundamentally different... Posted Dec 17, 2011 21:51 UTC (Sat) by khim (subscriber, #9252) [Link] Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. Why? Touchscreen. Manipulations with touchscreen only feel "natural" if image on screen follows finger without jitter. For that you need to redraw image on screen in 16ms or less. The only way to do that in a lot of cases is to use shadow buffers. Especially if you don't know the exact specifications of the target phone platform and can not guarantee that you'll be able to draw everything in 16ms using just abstract representation of your application state. Now, you can flush all these buffers when your application goes to background and restore them when it returns - but that requires cooperation from application side and is awfully similar to that dreadful "checkpoint/restore stuff". Besides if application is going to background for a short time it may not be a good idea to throw all these buffers right away (battery life, you know), so in the end you'll come up with scheme quite similar to what iOS/Android are doing. You may say: but I don't want all that fancy touchscreen stuff! Give me good multitasking instead! Well, may be you don't need it, but handset makers surely do: fate of Blackberry/Symbian/etc says that most people do want that touchscreen stuff - and if you'll take in account this requirement then suddenly resources of modern phones are not "overwhelming" but "just barely enough"...
PCs and phones are fundamentally different... Posted Dec 18, 2011 1:24 UTC (Sun) by pboddie (subscriber, #50784) [Link] Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. In general it is an optimisation. Your applications all have to be able to render themselves, but a decision has been taken that they won't be asked to do so in various circumstances because they will appear too slow or won't look very nice. If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state.
PCs and phones are fundamentally different... Posted Dec 18, 2011 7:52 UTC (Sun) by yoush (subscriber, #38940) [Link]
I don't really understand why you people are talking about framebuffer content saving here. This is *not* what is happening in Android.
If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint.
Have you tried looking on thread? Posted Dec 18, 2011 8:57 UTC (Sun) by khim (subscriber, #9252) [Link] I don't really understand why you people are talking about framebuffer content saving here. Have you tried to look on the context of the discussion? This is *not* what is happening in Android. Sure, but the question is: why this is not what is happening in Android. If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint. Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen. And if you keep that in mind then suddenly your phone is not "orders of magnitude more powerful then old PalmOS devices" but "about 2-3 times more powerful then first PalmOS device". Most touchscreen shartphones today employ this technique not because their creators are stupid, but because it was the only way to create usable "magic tablet" using today's technology.
Have you tried looking on thread? Posted Dec 18, 2011 12:46 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen."
Maybe the misunderstanding here is not differentiating between the memory requirements of running vs. stopped applications, and the associated state transitions.
It seems that if many apps (which ones?) use large pixmap caches during operation, *and* these are all retained in RAM while the apps are stopped, *then* perhaps overall RAM consumption can be said to be proportional to framebuffer sizes.
If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no.
Have you tried looking on thread? Posted Dec 18, 2011 14:45 UTC (Sun) by khim (subscriber, #9252) [Link] It seems that if many apps (which ones?) use large pixmap caches during operation Practically all applications do that. Even simple list of things need background pixmap or else you'll be unable to scroll it smoothly. *and* these are all retained in RAM while the apps are stopped Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly? If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no. Sure. "No large pixmaps" is BlackBerry/Symbian model which provides abysmal touchscreen experience. And to rely on the voluntary cooperation between applications is just silly: both MacOS Classic and Windows 3.x did that and it was awful. At least with save/restore model badly written application can only make experience awful for user when s/he actively uses this application. "Let's all work together" model makes it impossible to understand what exact application makes your system unusable. All systems which tried that (Maemo, Symbian, Windows Mobile) were constant battlefield because of that.
Have you tried looking on thread? Posted Dec 19, 2011 12:36 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
"Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. ... If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly?"
The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. The question is whether apps or the OS treat those pixmaps at a save/restore as a disposable cache, thus saving memory.
Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. Stopped application state could be swapped by the OS instead of by the app. If pixmaps form such a core element of this platform, then specially handling them (disposing them also in the compositor/OS) seems workable. If not, I'd like to understand why.
Have you tried looking on thread? Posted Dec 19, 2011 12:45 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The main reason to want to special-case the pixmap storage is that you'd want to be able to redraw that while the application is still restoring state - an expose event isn't going to be processed until you've pulled in everything needed to regenerate the UI, and a second of black screen followed by a responsive app is likely to be more distracting than a second of UI that doesn't respond. However, there's absolutely no reason that that has to be kept in RAM - I've no idea how Android does it, but grubbing through the filesystem on an iOS device reveals a pile of snapshots of applications.
The reason to have checkpointing built into the applications rather than the OS is that the kernel has no real idea which bits of data can be reconstructed and which are user input. Swapping the entire application would probably be massively slower than just serialising a small subset and pulling that back in.
I think you are mixing issues... Posted Dec 19, 2011 14:51 UTC (Mon) by khim (subscriber, #9252) [Link] The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Where this idea arrived from? Applications create shadow buffers for the express purpose of not doing recomputes later. Sure, OS and some toolkits may create cache buffers, too - but these are different. If mapping application converted vector map to pixmaps to make scrolling possible then the last thing it wants is to suddenly find out that OS decided to kill these pixmaps to save memory. If the whole application is killed and then restored then, of course, pixmaps will be recomputed, but otherwise they are kept in memory in the "ready to go" state... Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. Sure. Pixmaps determine minimal size of application. Of course it may (and often does) contain other information in memory, too. But of course the applications for which pixmaps are just a noise in their memory consumption are even larger thus it makes even less sense to try to use "proper multitasking" with them. Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. I always remember that, but it looks like you are forgetting sometimes. Ordinary unix approach is just to ignore expose events (window manager may change window borders, and application can usually ignore expose events completely). This is clearly inappropriate (as you yourself show) and everything else is just question of how much application should do to participate in checkpoint/restore dance.
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 8:48 UTC (Sun) by khim (subscriber, #9252) [Link] If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Nope. People don't understand this. Any OS which works like that will fail. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state. Well, it may be better for geeks like your and me, but it's much, much worse for Joe Average! People don't understand that application fill up the memory (heck, most need an explanation for what memory actually is first), if they understand then they forget all about it, etc. That's why set-top boxes with HDD remove (permanently remove at that!) old records, for example. People perceive smartphones not as electronic device, but as some kind of "magic tablet". They don't know and don't want to know how the whole thing works. That's why first iPhone was such a bomb: it was worse then most smartphones of the time (initially it had no support for apps!), but it was finally "magic tablet" which can be used without thinking about memory, tasks, etc. Sure, it had a lot of limitations (when you switched from one activity to another context was often lost, it had no copy-paste, etc), but it was finally usable by Joe Average, not just by eggheads!
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 14:06 UTC (Sun) by pboddie (subscriber, #50784) [Link] Nope. People don't understand this. Any OS which works like that will fail. I know you can't resist contradicting everyone, but plenty of people who don't work in software development are perfectly capable of realising that they have, in their own words, "filled up" or "overloaded" their device. You can argue that they have had to develop such notions through experience with technology that did not attempt to hide its own limitations, but people are pretty quick to notice and adapt to the limitations of things they use. It is also good design for devices to communicate their limitations gracefully. (And before you respond with the patronising "you don't get it - you're an egghead" remarks or rhetorical questions about whether people should be forced to micromanage their device's resources, just bear in mind that I'm not advocating anything of the sort. Being able to disregard the mechanisms involved and to have a device juggle potentially excessive resource demands is a form of liberation for the user, but it becomes a form of frustration if the user demands more than the device can deliver without being warned about it in advance.) I don't really know why I'm having this discussion: I don't even have a smartphone, and the benefits of running multiple applications at a time on a phone would probably be marginal for me. But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers.
I beg to differ... Posted Dec 18, 2011 14:57 UTC (Sun) by khim (subscriber, #9252) [Link] But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers. Well, this was "obvious" for phone makers from the onset: BlackBerry, Symbian, Windows Phone - they all supported multitasking for more then a decade. But then someone decided to "strip these benefits" in the favor of "useless eyecandy". And people beat records repeatedly in a rush to buy these phones with "suboptimal experience for users and developers"... Don't you think that this is... kind of strage? "Suboptimal experience" leads to record sales, rave reviews in press, etc? IMO it just shows that people have different values and for most "true multitasking" is simply less valuable then "smooth hassle-less experience"...
I beg to differ... Posted Dec 19, 2011 22:08 UTC (Mon) by pboddie (subscriber, #50784) [Link]
You always beg to differ. However, even the original iPhone was a success for a few factors other than the eye candy, which it probably doesn't have that much of in comparison to the recent models. Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era - and the willingness to have both WLAN and GSM on the same device, plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device.
Yes, sure. But how was Apple able to do that? Posted Dec 19, 2011 23:09 UTC (Mon) by khim (subscriber, #9252) [Link] Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era ...which Apple was able to offer because it knew browser can use all (or almost all) of the available memory since it'll be the only app running. and the willingness to have both WLAN and GSM on the same device Which was already old news at the time. iPaq 6315 in US and Nokia 9500 in the rest of the world offered the same capability three years earlier and in 2006 even midrange models like Samsung i730 and Nokia N80 had it. Sure, dual (GSM/WiFi) capability was important for iPhone but it was a means, not the goal. plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device. Oh, sure, YouTube was pretty big attraction. But this just shows that you can not reach success by just blindly showing features in your phone. You need an attractive experience - and if you can not deliver it and multitasking at the same timeĀ then multitasking must go. You may reintroduce it later when platform will be more capable. Even so Apple was not quite ready to add full multitasking to iPhone 4: apparently it was still not powerful enough. They introduced checkpoint/restore system which is even more limited then Android's one. It's all about tradeoffs and if your system is not powerful enough to support both multitasking and smooth, pleasant, experience then most people will want pleasant experience.
|
|||||||||||||