| |||||||||||||
Have you tried looking on thread?Have you tried looking on thread?Posted Dec 18, 2011 8:57 UTC (Sun) by khim (subscriber, #9252)In reply to: PCs and phones are fundamentally different... by yoush Parent article: 2011: The Year of Linux Disappointments (Datamation)
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.
(Log in to post comments)
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.
|
|||||||||||||