Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 8 hrs, 6 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 20 hrs ago - more...
| The Following User Says Thank You to EIPI For This Useful Post: | ||
 |
|
2010-06-14
, 22:51
|
|
Posts: 129 |
Thanked: 18 times |
Joined on Nov 2009
@ Switzerland
|
#12
|
Intriguing idea. I recon, technically, it should be doable. The necessary parts are open sourced, aren't they?
 |
|
2010-06-14
, 23:27
|
|
Posts: 431 |
Thanked: 239 times |
Joined on Apr 2010
@ London
|
#13
|
So I can put my 2 cents here since I was trying figure it out when I was working on Flaemo. Yes this is bloody Flash. But because of this fact Flash developers always facing performance issues. (That's why we are developers and problem solvers instead of programmers :P - chill out it was a little joke only)
But the way how Maemo desktop works make a lot of sense to me. I haven't seen a code at all. I guess it should tell me nothing anyway. But base on observation of behaviour I was trying to represent this behaviour as close as possible. Also I've been trying many different approaches. All I can say this is only for performance reason. Less elements on the screen under constant control, less performance impact. (pretty much Divide and Conquer is working here) That's why is more efficient handle 4 separate screens and make impression they are one strip rather other way around.
I know for user It could be cool to have more funky space and effects but they would never stop complain about battery drain instead and choppy movements. Don't forget that people behind any programmable solution doing stuff for reason. Doing decisions and very often compromises. I have no any little single bad world to say or complain about how Maemo (Linux desktops) functioning itself.
In fact it's very simple and it took me 4 classes (objects) to represent this in Flash. Because is simple is efficient and cool. Using this same approach you could have 100 desktop if you like without huge performance impact. Imagine this on one desktop.
And Another one example? Why you thing Google map is reading images only in area you already looking at? What you saying is like Would be cool to have huge Google Map of the entire World in max zoom and just scaling it and dragging around. If you can do a math this task is simply impossible to achieve by any broadband network and the best PC available on the market.
But the way how Maemo desktop works make a lot of sense to me. I haven't seen a code at all. I guess it should tell me nothing anyway. But base on observation of behaviour I was trying to represent this behaviour as close as possible. Also I've been trying many different approaches. All I can say this is only for performance reason. Less elements on the screen under constant control, less performance impact. (pretty much Divide and Conquer is working here) That's why is more efficient handle 4 separate screens and make impression they are one strip rather other way around.
I know for user It could be cool to have more funky space and effects but they would never stop complain about battery drain instead and choppy movements. Don't forget that people behind any programmable solution doing stuff for reason. Doing decisions and very often compromises. I have no any little single bad world to say or complain about how Maemo (Linux desktops) functioning itself.
In fact it's very simple and it took me 4 classes (objects) to represent this in Flash. Because is simple is efficient and cool. Using this same approach you could have 100 desktop if you like without huge performance impact. Imagine this on one desktop.
And Another one example? Why you thing Google map is reading images only in area you already looking at? What you saying is like Would be cool to have huge Google Map of the entire World in max zoom and just scaling it and dragging around. If you can do a math this task is simply impossible to achieve by any broadband network and the best PC available on the market.
|
|
2010-06-14
, 23:52
|
|
Posts: 422 |
Thanked: 244 times |
Joined on Feb 2008
|
#14
|
I think it is probably using standard X virtual desktops.
So when you slide, all that is really happening is a bitmap is taken of the current desktop, and transitioned to a bitmap of the next desktop, while behind the bitmaps the actual widgets are being rendered. Once the slide completes, the bitmap is removed to show the real desktop underneath.
It is an illusion. The reason I bring this up is it may appear to be just a case of switching off the "slide and stop" way the current desktop switching uses so you could have half and half for example, but it isn't really working that way - you could not interact with the widgets because they are just images of widgets.
It would take a bit of a rewrite of the desktop code. Still, nice idea though. Something 3x3 would be cool, with a button to zoom out to the "full desktop" so you could zoom in on a bit of it.
I think realistically the widgets already consume too many resources so this is asking for trouble.
So when you slide, all that is really happening is a bitmap is taken of the current desktop, and transitioned to a bitmap of the next desktop, while behind the bitmaps the actual widgets are being rendered. Once the slide completes, the bitmap is removed to show the real desktop underneath.
It is an illusion. The reason I bring this up is it may appear to be just a case of switching off the "slide and stop" way the current desktop switching uses so you could have half and half for example, but it isn't really working that way - you could not interact with the widgets because they are just images of widgets.
It would take a bit of a rewrite of the desktop code. Still, nice idea though. Something 3x3 would be cool, with a button to zoom out to the "full desktop" so you could zoom in on a bit of it.
I think realistically the widgets already consume too many resources so this is asking for trouble.
__________________
Servwise Advanced Hosting - Better, Faster, Smarter
Hum Consulting - IT and Marketing services to sing about
Servwise Advanced Hosting - Better, Faster, Smarter
Hum Consulting - IT and Marketing services to sing about
 |
|
2010-06-15
, 02:05
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#15
|
Originally Posted by paulkoan
I'm not sure what you mean; AFAIK X has no "standard virtual desktops". That's why every virtual wm on the planet implements them for itself. If I've missed something, please correct me.
I think it is probably using standard X virtual desktops.
So when you slide, all that is really happening is a bitmap is taken of the current desktop, and transitioned to a bitmap of the next desktop, while behind the bitmaps the actual widgets are being rendered. Once the slide completes, the bitmap is removed to show the real desktop underneath.
It is an illusion. The reason I bring this up is it may appear to be just a case of switching off the "slide and stop" way the current desktop switching uses so you could have half and half for example, but it isn't really working that way - you could not interact with the widgets because they are just images of widgets.
One might start simply by looking at it while sliding; you can't implement parallax with a single pixmap, so your explanation is obviously oversimplified at the least. Could be done with two pixmaps, of course, so that doesn't prove that you're completely wrong, but I bet if we cared to we could find out for sure in less than 5 minutes.
Since one can hold the desktop "between screens" indefinitely (just drag it to one side and don't release), all you'd need is some widget that will update without user intervention. Say, the media player applet -- seek to 10 seconds before the end of a file, then get to the desktop, drag and hold it halfway. Ok, I just went and did this (which took less time than it did to write up what I was going to do), and somehow the media player applet smoothly updated to the new file's title/artist info, and even scrolled it while being floated back and forth between desktops... a nifty trick for a pixmap, eh?
Now to me, this all makes sense, given that the same level of graphics acceleration for traditionally slow (and thus often cheated) wm eye-candy is seen elsewhere (dashboard), and that the need of hardware acceleration for the core desktop was the whole reason why Fremantle couldn't run on the N8x0.
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
| The Following User Says Thank You to Benson For This Useful Post: | ||
|
|
2010-06-15
, 02:13
|
|
Posts: 60 |
Thanked: 8 times |
Joined on Jan 2010
@ UK
|
#16
|
Originally Posted by paulkoan
i don't know about that because i can click a widget/short while the desktop is still sliding.
I think it is probably using standard X virtual desktops.
So when you slide, all that is really happening is a bitmap is taken of the current desktop, and transitioned to a bitmap of the next desktop, while behind the bitmaps the actual widgets are being rendered. Once the slide completes, the bitmap is removed to show the real desktop underneath.
It is an illusion. The reason I bring this up is it may appear to be just a case of switching off the "slide and stop" way the current desktop switching uses so you could have half and half for example, but it isn't really working that way - you could not interact with the widgets because they are just images of widgets.
It would take a bit of a rewrite of the desktop code. Still, nice idea though. Something 3x3 would be cool, with a button to zoom out to the "full desktop" so you could zoom in on a bit of it.
I think realistically the widgets already consume too many resources so this is asking for trouble.
|
|
2010-06-15
, 02:13
|
|
Posts: 431 |
Thanked: 239 times |
Joined on Apr 2010
@ London
|
#17
|
@paulkoan as Benson said. Nice guess but I am sure is not working that way either 
@Benson really? I'm new to maemo. If I was able to represent it in old flash 9 and is not GPU accelerated in any case. It was a key of incompatibility for N8x0?
I am really surprised.
Would you like to know how did I achieve that in flash?
I can even provide source code for slide desktop mechanism if somebody is interesting in.
Last edited by devu; 2010-06-15 at 02:15.
@Benson really? I'm new to maemo. If I was able to represent it in old flash 9 and is not GPU accelerated in any case. It was a key of incompatibility for N8x0?
I am really surprised.
Would you like to know how did I achieve that in flash?
I can even provide source code for slide desktop mechanism if somebody is interesting in.
__________________
My Toys: N900, Samsung Nexus S
Flaemo - Web based OS for Flash-enabled devices, more info here
My Toys: N900, Samsung Nexus S
Flaemo - Web based OS for Flash-enabled devices, more info here
Last edited by devu; 2010-06-15 at 02:15.
|
|
2010-06-15
, 05:42
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#18
|
Originally Posted by Benson
Unless later Xorg versions have expanded on the X protocol I think you're right.
I'm not sure what you mean; AFAIK X has no "standard virtual desktops". That's why every virtual wm on the planet implements them for itself. If I've missed something, please correct me.
X rendering is based on a root window which is something else than "a desktop". Typical "virtual desktoping" is done by manipulating and remembering which window should be displayed where depending on which virtual desktop is to be seen as active.
The Maemo approach is something else, just as you show with your experiment.
|
|
2010-06-15
, 06:12
|
|
Posts: 422 |
Thanked: 244 times |
Joined on Feb 2008
|
#19
|
Ooh. Looks like I made some assumptions before posting
Yeah, my apologies, by "Standard X" I wasn't really referring to X I guess but in the way virtual desktops are implemented under wms are fairly standard in how they achieve what they do, even if X is not doing the work.
So I assumed that Maemo was doing a similar thing. Even if not - the issue of parallax and changing pixmaps and pixmap overlays is trivial. Take a look at Compiz or KDE compositing to see what you can do - you can even have video running on the Cube while you switch desktops - but this is still not a real window that you can click on and interact with.
The compositing is done over the top. I think the same thing happens on Maemo, and ultimately the X is told what to render while the swipe happens. Even the act of clicking on an icon mid swipe isn't that big a deal - just subtract the swipe position from the normal screen position and "click".
Yeah, my apologies, by "Standard X" I wasn't really referring to X I guess but in the way virtual desktops are implemented under wms are fairly standard in how they achieve what they do, even if X is not doing the work.
So I assumed that Maemo was doing a similar thing. Even if not - the issue of parallax and changing pixmaps and pixmap overlays is trivial. Take a look at Compiz or KDE compositing to see what you can do - you can even have video running on the Cube while you switch desktops - but this is still not a real window that you can click on and interact with.
The compositing is done over the top. I think the same thing happens on Maemo, and ultimately the X is told what to render while the swipe happens. Even the act of clicking on an icon mid swipe isn't that big a deal - just subtract the swipe position from the normal screen position and "click".
__________________
Servwise Advanced Hosting - Better, Faster, Smarter
Hum Consulting - IT and Marketing services to sing about
Servwise Advanced Hosting - Better, Faster, Smarter
Hum Consulting - IT and Marketing services to sing about
|
|
2010-06-15
, 12:43
|
|
Posts: 129 |
Thanked: 18 times |
Joined on Nov 2009
@ Switzerland
|
#20
|
Originally Posted by paulkoan
On the contrary, While being on the cube, screenobjects can be manipulated, interacted with and moved around. I once tried this back in the days on Ubuntu 5 or 6. Was fun but no use, so I went back to Windows.
Take a look at Compiz or KDE compositing to see what you can do - you can even have video running on the Cube while you switch desktops - but this is still not a real window that you can click on and interact with.
Originally Posted by paulkoan
Well, no. As said, it's hardware-accelerated. Check the wikipedia article on how compositing is achieved. There are no pixmaps involved, at all. http://en.wikipedia.org/wiki/Compositing_window_manager It's rendered in the buffer, manipulated, and then drawn. Not the other way round.
...X is told what to render while the swipe happens. Even the act of clicking on an icon mid swipe isn't that big a deal - just subtract the swipe position from the normal screen position and "click".
 |
| Tags |
| stop thinking, totally lame |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 01:48.
http://www.slideshare.net/peterschne...ogy-highlights
Slide 9
Mobile Tablets Blog
Follow me on Twitter