What Will Be The Ui?

[DrOctavius]

My understanding is that it's not Xserver + Xlib that is slow to start but the billions of libraries KDE/Gnome rely on that are just layers above Xlib.

At least a few years ago (read: long before Qt and glib) X started quickly.

The problem is not the time it takes to launch.... if not when you benchmark graphic primitives like: lines, fills, bitblt, etc.
Some tests in NEO1973 shows X11 with an overhead of 50% vs framebuffer.

Sure that more layers above that will make it slower... (this is the price you pay for abstraction)

 

[ldesnogu]

The problem is not the time it takes to launch.... if not when you benchmark graphic primitives like: lines, fills, bitblt, etc.
Some tests in NEO1973 shows X11 with an overhead of 50% vs framebuffer.

Sure that more layers above that will make it slower... (this is the price you pay for abstraction)

That certainly highly depends on the HW you target. I am ready to bet most X servers are HW accelerated while most FB are not.

 

[sindbad]

That certainly highly depends on the HW you target. I am ready to bet most X servers are HW accelerated while most FB are not.

And you would win that bet The benchmark on the openmoko was done before Xglamo (hw acc kdrive).

 

[Squidge]

I guess it depends what types of applications people decide to write. With SDL apps (for them to be compatible with the "simple mode", they would need to be SDL anyway), I can imagine all of them being 800x480 resolution, requiring no window decorations, and the most "window management" required would be to simple toggle between the multiple fullscreen running applications. Which wouldn't be very difficult to write if you just provide a list of running applications to select from and switch to, as I was talking about earlier.

First app runs, SDL grabs a pointer to the frame buffer and the app writes it's stuff to the screen.
You press the 'magic button' to go back to the menu. The menu then somehow pauses the first app and redisplays the main menu.
Second app runs, SDL grabs a pointer to the frame buffer and the app writes it's stuff to the screen.
You press again the 'magic button' to go back to the menu. The menu then somehow pauses the second app and redisplays the main menu.
You choose to go back to the first app so the menu unfreezes the app. The first wasn't aware that it got frozen, so just continues from where it left off. Now you have a corrupted display since the app assumed exclusive access to the frame buffer, so doesn't bother updating the entire display - just the parts it needs updating. Its timers are also completely wrong now, so it now thinks it managed to display a single frame in the last 30 seconds (the time the menu and the second app was running), so adjusts itself accordingly.

So without both apps knowing what can happen to them (and when it happens), it's doesn't seem so simple?

 

[Svartalf]

So without both apps knowing what can happen to them (and when it happens), it's doesn't seem so simple?

It seems "simple" because so many are unaware of all the things you have to do to make it look simple. You need something to manage the access to the display's famebuffer. Whether this is X11, DirectFB, or whatever, you need to have something to handle all those details. People keep saying X11 is big, etc. It's not- there's a reason they did what they did with Maemo on the Nokia N770/N8x0 units.

The answer, if people are really concerned about performance (which I think they shouldn't be so much so...), is to do something along the lines of DirectFB, if TI's PowerVR support allows it (there's the rub, now isn't it?), where you have a goodly amount of acceleration at the framebuffer level, have a manager that handles the problems you brought up, and then has a loadable X11 server that sits atop the hardware accel manager layer and presents X11 to apps. You'd be surprised at how "thin" all of that actually ends up being.

 

[pupnik]

There is a lot to be said for keeping a simple unitask launcher but people are quite right that running a full mini Linux distro on the thing is also very appealing.

So what about a basic unitask launcher with an advanced mode that can be launched on demand (think X server with some form of PDA skin)?

Double-plus Good.

The uni-task option also makes it easier to write something like a music player is guaranteed to run in low-power mode.

I never boot my PC into runlevel 5 but instead to console. There's something elegant about a machine not starting a bunch of crap you don't need when powering-on.

But.. As others have mentioned here, being able to use the Pandora as more than just an emu-box will be an important feature. EABI is 'right'. Beyond that i don't know what the best choice is. I do think it's important to keep in mind the driving goal as bringing existing open-source apps to Pandora. Picking a half-baked 'future-cool' ui framework is not going to yield a Pandora with a robust 'PDA OS' sporting a wealth of usable apps by the end of 2008.

Don't let pride and tech geekiness lead you down a long and rocky path to get to your end-users. Take the short route.

(edit) And one such short route is Maemo/Mamona.

 

[Dutch_Cap]

FB for advanced menu is fine, but then you want multiple processors and the ability to swap between them. Doesn't that mean those processes need to be built with that in mind using some kind of library? It seems daft to do all that work when it's all been done for us already via X and a suitable Window manager.

Well, managing a bunch of windows with existing WMs will be tedious and annoying with existing WMs, so at least a WM will probably need to be developed specifically for the device anyway.

It's not like we're the first people who want a window manager for handhelds, you know...

 

[efegea]

I'll assume that X11 will be the default and for more cpu-intensive apps like an N64 emulator X11 will be killed and restored when the emulation session have been finished.

So I'll code a Qt4 GUI for X11 with matchbox as window manager

Tom Cooksey, how can I get effects like the ones on the iphone using Qt/X11? Will it use opengl ES hardware acceleration? If so, will all the widgets be accelerated or do I have to use QGLWidget? If so, is possible to render all kind of widgets inside a QGLWidget and will be they hardware accelerated? All I want is hardware accelerated transformations and blending.. for things like when on the iphone you drag an application icon and move it to another place..

Windows transitions will not be avaliable because matchbox doesn't support it..and I don't know if the X server used on the pandora will support opengl windows..

 

[TomCooksey]

Tom Cooksey
Windows transitions will not be avaliable because matchbox doesn't support it..and I don't know if the X server used on the pandora will support opengl windows..

I am working on getting QGLWidget to work with OpenGL ES & EGL on X, it's currently a work in progress but expect it in the next few months. Obviously you'll need to limit yourself to OpenGL ES calls in your QGLWidget. There's a Qt demo showing off OpenGL ES as part of Trolltech's port to windows CE if you want an example.

HOWEVER, this assumes that X will support OpenGL ES & EGL. As far as I can tell, this will not be the case - no X applications (Qt or anything else) will be able to use the OpenGL ES on the device (kinda hope I'm wrong on this one!).

 

[efegea]

So we need info from the system developers..Craig, DaveC, DJWillis, Ed, Fatih, Michael, Squidge..? Do anyone know if hardware acceleration will be avaliable for X applications? Will be a big error if not..


Tom Cooksey, so if I use QGLWidget I only can use opengl calls, that's not what I want.. I want to use native Qt widgets so I'll forget the opengl thing, but I hope Qt will support some kind of hardware acceleration so we can have cool effects..

This kind of things are what make me to forget the idea of making a GUI, there is not enough info!

 

[TomCooksey]

Tom Cooksey, so if I use QGLWidget I only can use opengl calls, that's not what I want.. I want to use native Qt widgets so I'll forget the opengl thing, but I hope Qt will support some kind of hardware acceleration so we can have cool effects..

Ah, I miss-understood what you were asking. If you're just restricting yourself to the Qt API and don't want to use OpenGL calls yourself, Qt will be accelerated. On X11 for example Qt will use the XRender extensions if avaliable.

There is also the possibility of making Qt render widgets using OpenGL, this is done using the OpenGL paint engine. However, Qt is very vector-graphics orientated and we've found using the OpenGL paint engine for normal 2D widgets is actually slower than software rendering. Having said that, using the OpenGL paint engine for graphics view applications is much faster than software rendering. Graphics view will cache items as textures and then draw those textures onto the canvas very quickly. So, if you have OpenGL avaliable, you can get some stunning effects & animations using graphics view.

 

[efegea]

Is the "widgets on the canvas" new Qt 4.4 feature what I need? I was just googling and found that.

 

[TomCooksey]

You can use widgets on graphics view, but if you don't need full QWidget functionality, you're probably better off just sticking with regular QGraphicsItems. Widgets on canvas are meant for when you _need_ a widget e.g. for text entry you can use a QLineEdit. QGraphicsItems are better optimized and probably faster. Check out the Graphics View Documentation and the Graphics View Examples (Colliding mice is my favorite!)

 

[chad78]

I really hope the UI is like this.

In fact, if any one of you uber talented, smart, clever, good looking, and suave developers wants to give me a hand in making a demo, I'd be your BFF and a day!

 

[TomCooksey]

I've replied to the other thread to keep this one on-topic. Very nice tho!