Reply
Thread Tools
Posts: 14 | Thanked: 31 times | Joined on Jan 2010 @ Helsinki
#21
And here is the video....
<removed youtube link>

sorry guys, no video.

Last edited by dubik; 2010-02-16 at 18:54.
 

The Following 3 Users Say Thank You to dubik For This Useful Post:
Posts: 92 | Thanked: 127 times | Joined on Oct 2009 @ Italy
#22
Video is private?
__________________
aka Amby over @ meego

Vote on the N900 in the Engadget Awards!
My continously built proposal(-devel) for maemo.org community.
Do you want to save your favourite thing about maemo & community? Make sure you list it here.
 
qgil's Avatar
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#23
nibbles, you are getting confused. That article is quite old and this thread is about the open development of the Harmattan UI framework. Posts moved to the (old) thread where they belong to: http://talk.maemo.org/showthread.php?t=29055
 

The Following 2 Users Say Thank You to qgil For This Useful Post:
Posts: 4 | Thanked: 4 times | Joined on Feb 2010
#24
Since I didn't find place to discuss UI framework detail, I put some comments here (so it isn't as open as I expected ):

-- Why is the compositor based on QGLWidget instead of QWidget?
This implies that this UI framework requires HW OpenGL support all the time, similar to clutter.

This makes it less flexible when porting to a system w/o OpenGL and at least makes it more difficult to port as OpenGL driver is always closed source and not available from the beginning. (Actually, this is worst thing I think with Moblin).

-- Qt provides graphic system support, which make it possible to render using OpenGL or not. That is the flexibility I like with Qt. As such a fundamental component, using QWidget will provide more scalability. I like the idea in http://labs.trolltech.com/blogs/2009...e-an-overview/, which basically suggest to use SW raster engine by default and use QGLWidget when OpenGL acceleration is needed.
 

The Following 2 Users Say Thank You to ezjd For This Useful Post:
Posts: 1 | Thanked: 4 times | Joined on Feb 2010 @ Helsinki, Finland
#25
Originally Posted by ezjd View Post
Since I didn't find place to discuss UI framework detail, I put some comments here (so it isn't as open as I expected ):

-- Why is the compositor based on QGLWidget instead of QWidget?
This implies that this UI framework requires HW OpenGL support all the time, similar to clutter.

This makes it less flexible when porting to a system w/o OpenGL and at least makes it more difficult to port as OpenGL driver is always closed source and not available from the beginning. (Actually, this is worst thing I think with Moblin).

-- Qt provides graphic system support, which make it possible to render using OpenGL or not. That is the flexibility I like with Qt. As such a fundamental component, using QWidget will provide more scalability. I like the idea in http://labs.trolltech.com/blogs/2009...e-an-overview/, which basically suggest to use SW raster engine by default and use QGLWidget when OpenGL acceleration is needed.
The Harmattan UI platform _is_ an OpenGL/GLES2-based platform and that backend is intentional. We are going to publish some validation test suites for hardware that can support our platform so this will not really be a big issue (e.g., GL extensions, shader support, etc).

Actually what Gunnar was talking in his blog is how off-screen painting is being handled. This is now made default in Qt i.e.,QPainter renders graphics to an off-screen buffer before displaying it on the framebuffer. The raster engine is of course the fastest off-screen painting approach because not all platform support GL rendering to pixmaps. Now how to render that off-screen buffer to the frame buffer is another issue, which of course the most efficient manner is by using GL.

Our compositor does not need to use raster because it completely bypasses QPainter since it is only interested in windows and already has the reference to off-screen representation of windows. What it needs is just a surface to draw to. That is why you see QGLWidget.
 

The Following 4 Users Say Thank You to xynopsis For This Useful Post:
Posts: 95 | Thanked: 12 times | Joined on Feb 2010
#26
Dont install the demo widget.. Your themes would not work
 
Posts: 4 | Thanked: 4 times | Joined on Feb 2010
#27
Originally Posted by xynopsis View Post
The Harmattan UI platform _is_ an OpenGL/GLES2-based platform and that backend is intentional. ...
OK, I am more clear about Harmattan targeting platform, which invalidates my comments basically. Looks like I should send this kind of requirement to MeeGo project, esp. assuming Harmarran UI framework will be the base of MeeGo's.

Technology wise, I'd say it will be more flexible that compositor can "fallback" to use QWidget or even QWindowSurface(?) when GL support isn't available or at least provides compile time options. One example is KWin, which can run well with or w/o GL support.
 
Posts: 7 | Thanked: 135 times | Joined on Nov 2009
#28
Originally Posted by ezjd View Post
Technology wise, I'd say it will be more flexible that compositor can "fallback" to use QWidget or even QWindowSurface(?) when GL support isn't available or at least provides compile time options. One example is KWin, which can run well with or w/o GL support.
Our compositor is really small (both code and feature wise) and intently focuses on filling the niche of a high-performance OpenGL compositor for handhelds or slightly larger devices. It's not really something you would want to use even on your laptop at this time. It does some quite innovative things like seamlessly un-redirecting the rendering for windows that fill the device screen, which is perfect for a handheld but doesn't make sense in other type of setups.

That said, the Harmattan UI framework can, and has been, run with other window managers and compositors. The apps don't really make any assumptions in this regard. Still, while the apps can technically be run in software by switching the graphics system, we see it as critical to the user experience that we can depend on OpenGL acceleration being available to us. So we are setting the minimum hardware baseline at the N900 level for the entire framework, and not making any compromises in order to also scale downwards.
 

The Following 3 Users Say Thank You to tomasj For This Useful Post:
Posts: 4 | Thanked: 4 times | Joined on Feb 2010
#29
Originally Posted by tomasj View Post
Our compositor is really small (both code and feature wise) and intently focuses on filling the niche of a high-performance OpenGL compositor for handhelds or slightly larger devices. It's not really something you would want to use even on your laptop at this time. It does some quite innovative things like seamlessly un-redirecting the rendering for windows that fill the device screen, which is perfect for a handheld but doesn't make sense in other type of setups.
I understand the reason doing so. What is this "seamlessly un-redirecting rendering"?

Originally Posted by tomasj View Post
That said, the Harmattan UI framework can, and has been, run with other window managers and compositors. The apps don't really make any assumptions in this regard. Still, while the apps can technically be run in software by switching the graphics system, we see it as critical to the user experience that we can depend on OpenGL acceleration being available to us. So we are setting the minimum hardware baseline at the N900 level for the entire framework, and not making any compromises in order to also scale downwards.
As I assume (somewhat confirmed) that Harmattan UI framework will be the base of MeeGo, I think it was targeting much more devices. So I have these ideas because I view it as a more generic compositor and technically it is easy to achieve with Qt. Probably MeeGo will do another window manager/compositor, though it might not as HW OpenGL is also assumed, at least to what I heard.
I really like the graphic system/backend thing of Qt, which makes it possible to use OpenGL or not and it is transparent to application and can be changed at runtime. And this is impossible in clutter based system.
 

The Following 2 Users Say Thank You to ezjd For This Useful Post:
Venemo's Avatar
Posts: 1,296 | Thanked: 1,773 times | Joined on Aug 2009 @ Budapest, Hungary
#30
I installed duitheme, because I liked its nice plain white look.
After that, I couldn't switch to the actual theme, because tapping on the "Themes" item didn't work anymore.

I didn't install any of the other packages.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 02:24.