Active Topics
-
[ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900 (2,264)
to Maemo 5 / Fremantle by panjgoori - 1 day, 15 hrs ago -
Porting apps to Leste (31)
to Maemo 7 / Leste by HtheB - 1 day, 22 hrs ago -
Full linux distros on Sailfish OS (254)
to SailfishOS by qoh - 2 days, 13 hrs ago - more...
 |
|
2009-10-18
, 02:37
|
|
Posts: 117 |
Thanked: 32 times |
Joined on Oct 2009
@ USA
|
#22
|
Originally Posted by ysss
If you'd like to reform the entire scientific publishing establishment, be my guest. Or perhaps you could code a PDF reflower. Please note that it must reflow scanned articles as well; just because a paper was from the 1960s, doesn't meant that it's useless!
The main problem here is that your intended document was not designed to be displayed in small screens in the first place. If it was, then it should support reflow-able text.
To take this issue to the extreme, imagine trying to read a plain 'ol newspaper rendered as a PDF. You can ask for a 2560x2048 3.5" screen (or whatever) to be able to render the whole width of the content but you'll still end up finding the bottleneck elsewhere (your eyes).
Sadly, the screen is the easier thing to fix IMHO.
__________________
--
Umm, what?
--
Umm, what?
|
|
2009-10-18
, 02:40
|
|
Posts: 117 |
Thanked: 32 times |
Joined on Oct 2009
@ USA
|
#23
|
Originally Posted by ragnar
Please quantify. I certainly agree that, in principle, more pixels => slower. However, how much slower is the question.
The 770 didn't run 800x480 well, the framerates were generally bad. Let's not fool ourselves with that.
The performance would decrease with increased resolution. What the cpu speed is doesn't have a direct correlation here. The display bandwidths are mostly separate, although you naturally need the cpu in determining what the content on screen should be. That's not the bottleneck in most cases: processing and determining the content doesn't take so much cpu power.
Simplying the issue, one can say that the amount of pixels you can push on screen per second is fixed. The more pixels each frame has, the less frames per second you can do. If the device would be 480x320 resolution, it would be a lot faster in many cases.
__________________
--
Umm, what?
--
Umm, what?
|
|
2009-10-18
, 03:11
|
|
Posts: 452 |
Thanked: 522 times |
Joined on Nov 2007
|
#24
|
800x480 = 384000 Pixels
1024x600 = 614400 Pixels
1280x720 = 972800 Pixels.
By jumping from the current screen size to 1024x600 you almost double the amount of pixels per screen refresh. If you jump to 1280 it is almost 3 times the amount of pixels. This would mean the processor/graphics system would have to handle a LOT more data per-refresh.
Nathan
1024x600 = 614400 Pixels
1280x720 = 972800 Pixels.
By jumping from the current screen size to 1024x600 you almost double the amount of pixels per screen refresh. If you jump to 1280 it is almost 3 times the amount of pixels. This would mean the processor/graphics system would have to handle a LOT more data per-refresh.
Nathan
|
|
2009-10-18
, 16:53
|
|
Posts: 117 |
Thanked: 32 times |
Joined on Oct 2009
@ USA
|
#25
|
Originally Posted by Nathan
And what is it capable of? What lag would we be discussing? I'm well familiar with how to caculate the number of pixels; 1024x600 is (approximately) 4 and a half times the number of pixels in 480x281. That doesn't tell us how much faster 480x281 is than 1024x600.
800x480 = 384000 Pixels
1024x600 = 614400 Pixels
1280x720 = 972800 Pixels.
By jumping from the current screen size to 1024x600 you almost double the amount of pixels per screen refresh. If you jump to 1280 it is almost 3 times the amount of pixels. This would mean the processor/graphics system would have to handle a LOT more data per-refresh.
Nathan
Give me actual performance information. What is the n900 capable of pushing at what rate? Benchmarks on the various devices would be nice too.
__________________
--
Umm, what?
--
Umm, what?
|
|
2009-10-18
, 17:38
|
|
Posts: 117 |
Thanked: 32 times |
Joined on Oct 2009
@ USA
|
#26
|
FWIW, TI says OMAP3430 supports up to 1024x768. (http://focus.ti.com/general/docs/wtb...emplateId=6123)
I'd presume that it should work "fine" (for whatever they determine to be "fine") at that resolution.
I'd presume that it should work "fine" (for whatever they determine to be "fine") at that resolution.
__________________
--
Umm, what?
--
Umm, what?
|
|
2009-10-18
, 17:55
|
|
Posts: 117 |
Thanked: 32 times |
Joined on Oct 2009
@ USA
|
#27
|
Well, a Nokiite sez that the OMAP3430 doesn't have the memory <-> GPU bandwidth for 1024x768, so the idea is pretty dead for the n900 (which is true anyway). Perhaps not for later versions, however.
__________________
--
Umm, what?
--
Umm, what?
| The Following User Says Thank You to solarion For This Useful Post: | ||
|
|
2009-10-18
, 20:58
|
|
Posts: 452 |
Thanked: 522 times |
Joined on Nov 2007
|
#28
|
Originally Posted by solarion
Two things along about this. Just because the device "supports" it; doesn't mean it supports it well. I've seen a lot of graphics cards in my 20 years say they "support" x; but really they support x / 2 well.
FWIW, TI says OMAP3430 supports up to 1024x768. (http://focus.ti.com/general/docs/wtb...emplateId=6123)
I'd presume that it should work "fine" (for whatever they determine to be "fine") at that resolution.
Second, Since this is a embedded OpenGL/es device also; their is no probably way the /es portion would probably support 1024x768 at any decent frame rate. In fact I personally hope the OpenGL/es device can handle the current resolution at a good frame rate.
Nathan.
 |
|
2009-10-18
, 21:48
|
|
Posts: 29 |
Thanked: 13 times |
Joined on Jan 2009
@ Bulgaria
|
#29
|
I fail to see how adding more pixels will help anyone reading a PDF. Adding more pixels and increasing the display size sure will, but we'll be moving out of phone territory then.
|
|
2009-10-18
, 22:09
|
|
Posts: 716 |
Thanked: 303 times |
Joined on Sep 2009
@ Sheffield, UK
|
#30
|
Personally, I wish it had HDMI output on the thing and allowed at least a higher resolution for that. It could have been really useful for presentations via a projector, monitor, HDTV, etc.
In fact, it could have asked you if you want "TV Out" or "PC Mode" when plugging in the HDMI cable. PC Mode being a full lightweight window manager with mouse cursor etc, like a desktop PC. It could support bluetooth keyboard and mouse or even switch the touchscreen into touchpad mode so it could work without any extra peripherals at all.
Apart from the lack of a HDMI port and perhaps not enough space on root, I suspect the hardware would be perfectly capable of this comfortably including 720p video playback as there have already been confirmation that it downscales 720p to 800x480 without any problems. (granted, that does not prove the GPU can push 1280x720 at 60fps)
I think its only a matter of time before we have this in our pockets. There are already UMPCs that can do this, but they are so expensive. But I totally expect ARM to be able to handle this too, its just nobody is vying for that market yet.
Last edited by Alex Atkin UK; 2009-10-18 at 22:14.
In fact, it could have asked you if you want "TV Out" or "PC Mode" when plugging in the HDMI cable. PC Mode being a full lightweight window manager with mouse cursor etc, like a desktop PC. It could support bluetooth keyboard and mouse or even switch the touchscreen into touchpad mode so it could work without any extra peripherals at all.
Apart from the lack of a HDMI port and perhaps not enough space on root, I suspect the hardware would be perfectly capable of this comfortably including 720p video playback as there have already been confirmation that it downscales 720p to 800x480 without any problems. (granted, that does not prove the GPU can push 1280x720 at 60fps)
I think its only a matter of time before we have this in our pockets. There are already UMPCs that can do this, but they are so expensive. But I totally expect ARM to be able to handle this too, its just nobody is vying for that market yet.
Last edited by Alex Atkin UK; 2009-10-18 at 22:14.
The performance would decrease with increased resolution. What the cpu speed is doesn't have a direct correlation here. The display bandwidths are mostly separate, although you naturally need the cpu in determining what the content on screen should be. That's not the bottleneck in most cases: processing and determining the content doesn't take so much cpu power.
Simplying the issue, one can say that the amount of pixels you can push on screen per second is fixed. The more pixels each frame has, the less frames per second you can do. If the device would be 480x320 resolution, it would be a lot faster in many cases.