Slim Ui/launcher

[TomCooksey]

I've been thinking about the UI again. As many have pointed out, having X or Qt/Embedded is way too heavy for the usecase where you power on and want to game ASAP. So, what's the alternetive?

An ultra-slim UI/Launcher is perhaps the best option. Something with minimal memory requirements and (near) instant load time. The launcher can always "launch" X or Qt/E or whatever full-featured UI you want. This is a barebones app which lets you get to games as fast as possible and gives them as much memory as possible. If you want to do anything like instant messenger, web browsing, e-mail, etc, you launch the full-blown UI.

I'm not sure what the plan is for suspend/power off on the Pandora? If the plan is to power off, then we need to go from power-on to UI in the quickest time possible. I've worked on another project which used this approach. On shutdown, we grabbed a screenshot, converted it to grayscale and saved it in a flash partition. The first thing the bootloader did was load the image into the framebuffer. When the app was loaded, it re-rendered in colour. Having a grayscale image during boot was enough of a visual cue to the user that the device was on, but couldn't be used yet. We could do a similar thing with the launcher? Of course if the plan is to suspend and not power down, this is less of an issue.

Is the idea is suspend, I'd recomend not trying to suspend during 3D games. I believe the game would have to be modified to know it has come out of suspend and re-initialise the SGX.


My final thought is that this launcher doesn't have to be ugly. It could be written in pure OpenGL ES and still be small.

Thoughts? Probably not exactly an original idea!

 

[mindlord]

I hate to say it, but a little bit of research goes a long way here.
This topic is one of interest to me, and I posted a question very much like this several weeks ago. I read just about every post the gets written to these forums, so let me try to short answer you here.

Because the Pandora is a "well known" hardware platform the linux kernel and X install that will be used on it will be tailored to it's hardware spec and will load extremely fast (according to Squidge). So load time for a X based Gui is not that big a deal, if you really want that 2 seconds that badly then by all means use a framebuffer UI. When using an X based UI and launching something intense like a N64 emulator. X will unload from memory, and free up those resources so the app can have them and then reload itself once the app is finished.

When the Pandora suspends, I do not believe it's quite like a laptop. It basically just shuts off all non-essential hardware, turns off the LCD, and puts the CPU into a sleep state that uses very little (if any) power. The RAM continues to be refreshed in this state, but speculations are that it can sit like this for very long periods of time and not die. When the Pandora is re-awakened the hardware wakes up and the CPU starts chugging again and the program continues right were it left off like nothing at all happened. This shouldn't even matter if you're playing something 2D, surfing the web (as long as your wifi is still close), or playing Quake 3.

It is my understanding, at least from what I can gather from the tidbits around the forum, that the official UI is in fact not going to be X based. When Craigx hinted that he needed help porting the UI to windows he was looking for something to display his framebuffer data using SDL. Since he is working directly with the framebuffer that doesn't sound very X-like behavior to me. So, I doubt it is X based. Just an educated guess.

 

[sindbad]

Most of my cool ideas of software to make/adapt for the pandora will most likely require X and I'm sure I'm not the only one. It can be made very quick to start on uniform hardware and always keeping your pandora in sleep should work very well anyway.

 

[Chip]

When the Pandora suspends, I do not believe it's quite like a laptop. It basically just shuts off all non-essential hardware, turns off the LCD, and puts the CPU into a sleep state that uses very little (if any) power. The RAM continues to be refreshed in this state, but speculations are that it can sit like this for very long periods of time and not die.

It can sit for a couple months in sleep mode according to preliminary battery tests. Resume from sleep should take no longer than the various components require to wake up - probably under one second for everything except the wifi (usually takes a couple seconds at least to re-establish a connection). Alternately, there will be a hibernate mode which will copy the contents of the RAM to the SD card and shut down completely.

It is my understanding, at least from what I can gather from the tidbits around the forum, that the official UI is in fact not going to be X based. When Craigx hinted that he needed help porting the UI to windows he was looking for something to display his framebuffer data using SDL.

Due to overwhelming demand, things have most likely changed. The default UI will probably run under a very lightweight X server like kdrive. It is assumed that the system can kill the X server when needed for apps that need direct hardware control.