| |||||||||||||
PCs and phones are fundamentally different...PCs and phones are fundamentally different...Posted Dec 17, 2011 21:51 UTC (Sat) by khim (subscriber, #9252)In reply to: Sorry, my bad... by pboddie Parent article: 2011: The Year of Linux Disappointments (Datamation)
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"...
(Log in to post comments)
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.
|
|||||||||||||