Reply
Thread Tools
Posts: 129 | Thanked: 9 times | Joined on Jan 2008
#1
how is it that the n800 can play high quality 400x240 video absolutely perfectly for as long as u want without it skipping a beat at all

but if u open any SINGLE image higher than 1024x768, it becomes super slow and struggles to zoom or anything? i put in my Canon SD1000's memory card in the external slot and it takes like 4 minutes to open one JPEG. is this just because its big? 2048x1536?

it cant handle one big frame but it can handle processing thirty high quality 400x240 frames in ONE second? wth!
 
Posts: 5,335 | Thanked: 8,187 times | Joined on Mar 2007 @ Pennsylvania, USA
#2
Originally Posted by OppositeOfIgnorance View Post
it cant handle one big frame but it can handle processing thirty high quality 400x240 frames in ONE second?
Sure, because the Internet tablets don't have huge amounts of RAM. With video, the codec and whatever routines are used to draw to the screen are loaded into RAM, and then they pull in into RAM and discard one small chunk of data--a frame--after another.* The tablet never needs more than a small fraction of the video file in RAM at any given moment.

In contrast, to display a large image file, the tablet needs to read the entire file into RAM. First, the act of simply reading the entire, large image file will take more time than reading a tiny portion of a video file. Then, to fit the entire image file in RAM at once, the tablet may need to swap other applications and data out. If so, it's then waiting on writes to complete before it can finish reading, and writing is slow.


* This is simplifying the matter a bit. Most video codecs these days take advantage of interframe compression, so frames often aren't forgotten completely as soon as they're displayed. Even so, the size of the data that needs to be kept in RAM is small.
 
Posts: 7 | Thanked: 0 times | Joined on Feb 2008
#3
In contrast, to display a large image file, the tablet needs to read the entire file into RAM. First, the act of simply reading the entire, large image file will take more time than reading a tiny portion of a video file. Then, to fit the entire image file in RAM at once, the tablet may need to swap other applications and data out. If so, it's then waiting on writes to complete before it can finish reading, and writing is slow.
I don't think it 's the reason N800 processe big image file slowly.In my memory, there is a dos image-view software SEA.It even can view a big image than 1024 x 768 on my pentium-100 16M-Mo back to the year 1996.N800's cpu must far more fast than the pentium 100,and Memory is 8 times than the machine.Why can't N800 take a good care of a big image?I think it's a optimizition issue.(sorry for my poor English)
 
Johnx's Avatar
Posts: 643 | Thanked: 628 times | Joined on Mar 2007 @ Seattle (or thereabouts)
#4
Try another image viewer. Quiver and Mirage come to mind. There are specific optimizations for dealing with large image sizes and obviously they aren't in the built-in image viewer. Maybe file the bug as an enhancement request on bugs.maemo.org?

-John
 
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#5
while the community is doing good work in porting apps, its about time we get a simple way of making something other then the builtin apps the primary app for a filetype.
 
Johnx's Avatar
Posts: 643 | Thanked: 628 times | Joined on Mar 2007 @ Seattle (or thereabouts)
#6
I thought it was either Quiver or Mirage which automatically took over the mime-types for jpg and png when it was installed? Maybe I'm remembering incorrectly?
 
Posts: 91 | Thanked: 4 times | Joined on Dec 2007
#7
No both don't take over the mime types. You have to change it manually.
 
pipeline's Avatar
Posts: 693 | Thanked: 502 times | Joined on Jul 2007
#8
Quiver did 'used' to do that so possibly they left capability dormant for turning on. The most non-hackable component seems to be implementing code to handle the mime callback, which most likely is still there. Someone could try editing the .desktop or (service/mime?) config files to re-enable this before doing an update-mime-database.
 
Posts: 139 | Thanked: 24 times | Joined on Sep 2005
#9
Originally Posted by pipeline View Post
The most non-hackable component seems to be implementing code to handle the mime callback, which most likely is still there. Someone could try editing the .desktop or (service/mime?) config files to re-enable this before doing an update-mime-database.
No need, just edit /usr/share/applications/defaults.list. Changes for jpeg as an example:
Code:
## comment out the original jpeg mime handler
#image/jpeg=hildon-image-viewer.desktop

image/jpeg=hildon-quiver.desktop
Restart file manager and it should work.

It's a shame that the user versions of these files (like ~/.local/share/applications/defaults.list) do not work: It would have made a default-app-selector application very easy to code -- now it'll need root permissions, there's a chance of messing up the system defaults and system upgrades are going to be more difficult.
 
Posts: 129 | Thanked: 9 times | Joined on Jan 2008
#10
so it can go through 1800 400x240 pictures (technically) in a minute but it takes 2 to load a 2048x1536 JPEG.

can quiver do it? ive never looked into either alternate viewer
 
Reply


 
Forum Jump


All times are GMT. The time now is 01:51.