Written by zaryk the 29 Feb 08 at 15:57.

Ubuntu Brainstorm was updated in January 2009. Since the idea #1521 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #1521 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by xubaj the 27 Aug 09 at 01:18.

i don't know if Linux does this already but applications that are used frequently like Nautilus should be in RAM all the time.

the folder contents should be cached. the content may be changed by other applications (terminal) and Nautilus will loose track of the current content. either Nautilus should keep track of folder content even when closed or just fake the content based on the previous cache and already allow user interaction while streaming the current content in background.

an example:
content of /tmp is 100 files
Nautilus gets closed
in terminal i add 50 files
reopen Nautilus and navigate to /tmp
show old cache of 100 files and stream current state in background
if i click another folder (/tmp/test) or file while streaming, the current streaming is stopped and the new folder opened and thus wasting no time with folder updating when i already know where i want to go (/tmp/test)

i don't know if Linux does this already but applications that are used frequently like Nautilus should be in RAM all the time. the folder contents should be cached. the content may be changed by other applications (terminal) and Nautilus will loose track of the current content. either Nautilus should keep track of folder content even when closed or just fake the content based on the previous cache and already allow user interaction while streaming the current content in background. an example: content of /tmp is 100 files Nautilus gets closed in terminal i add 50 files reopen Nautilus and navigate to /tmp show old cache of 100 files and stream current state in background if i click another folder (/tmp/test) or file while streaming, the current streaming is stopped and the new folder opened and thus wasting no time with folder updating when i already know where i want to go (/tmp/test)

Written by Zatara214 the 9 Sep 09 at 23:14.

As per my comment below, I think OSX does something similar. To take it even further, maybe AWN could develop integration for this if implemented. This would be the optimal way of using this idea while still appealing to both sides of the argument.

As per my comment below, I think OSX does something similar. To take it even further, maybe AWN could develop integration for this if implemented. This would be the optimal way of using this idea while still appealing to both sides of the argument.

Written by Zatara214 the 10 Sep 09 at 05:56.

Come on, Firefox loads REALLY slowly and we all know it. Even with Preload installed, it's definitely one of the slowest loading programs installed by default (along with OpenOffice). If it was kept in memory, I think many more people would be willing to switch to Ubuntu based solely on the speed of the browser. Again, this should be optional, as it wouldn't help on older machines or machines with limited RAM.

Come on, Firefox loads REALLY slowly and we all know it. Even with Preload installed, it's definitely one of the slowest loading programs installed by default (along with OpenOffice). If it was kept in memory, I think many more people would be willing to switch to Ubuntu based solely on the speed of the browser. Again, this should be optional, as it wouldn't help on older machines or machines with limited RAM.

Written by adisk the 16 Sep 09 at 16:09.

Add option for disable MIME detection.
File type detection is very slow? because need open and read most files.
Detect MIME on click only. (on left-click and on right-click)

Option like "Disable MIME detection (for slow PC)"

Add option for disable MIME detection. File type detection is very slow? because need open and read most files. Detect MIME on click only. (on left-click and on right-click) Option like "Disable MIME detection (for slow PC)"

Written by Lachu the 28 Sep 09 at 13:40.

Disable mime detection for some system directories, like /bin, /sbin, etc.

Disable mime detection for some system directories, like /bin, /sbin, etc.

Written by Lachu the 8 Nov 09 at 19:59.

This will lack many think, because application can modify modification date, but also speed up folder opening operation.

Create cache and use kernel buffers. When application using GNOME file system layer, it's a great opportunity to regenerate preview, when file is closed and been modified. It can works for small files. How? Application closes file, using GNOME calls. GNOME will check if file was changed and regenerate preview, storing last modification date in special place.

When we open a folder, Nautilus compare only modification date. If user using only GNOME, all preview will been generated.

This will lack many think, because application can modify modification date, but also speed up folder opening operation. Create cache and use kernel buffers. When application using GNOME file system layer, it's a great opportunity to regenerate preview, when file is closed and been modified. It can works for small files. How? Application closes file, using GNOME calls. GNOME will check if file was changed and regenerate preview, storing last modification date in special place. When we open a folder, Nautilus compare only modification date. If user using only GNOME, all preview will been generated.

Written by mikko.rantalainen the 7 Oct 10 at 07:20.

The problem is very similar to the problem of rendering a web page: the process can get the rough content (a HTML page) quickly, but the referred content takes more time. Implement the same fix for the problem ("insert and render linked images / other resources as they come"):

Incremental rendering: immediately after the nautilus has received a file name from the OS, it should start rendering it. If current view mode is "Icons", the icon could first appear as empty/fully transparent rectangle of suitable size and later replaced with the real icon once the system knows it. The current implementation seems to be "never render anything until the full display with all the icons and stuff can be rendered".

Additional notes: try to make sure that label/icon placement is static from the start (reserve enough space for the final icon from the start), it would make sense to wait for 0.25 seconds before starting incremental rendering (compare to FOUC in web pages), improve caching (if nautilus has rendered /usr/bin 10 seconds ago, it shouldn't start the process from the start to get the correct icons and metadata), and finally animate (fade) between the different rendering states to make appearing icons less irritating.

The problem is very similar to the problem of rendering a web page: the process can get the rough content (a HTML page) quickly, but the referred content takes more time. Implement the same fix for the problem ("insert and render linked images / other resources as they come"): Incremental rendering: immediately after the nautilus has received a file name from the OS, it should start rendering it. If current view mode is "Icons", the icon could first appear as empty/fully transparent rectangle of suitable size and later replaced with the real icon once the system knows it. The current implementation seems to be "never render anything until the full display with all the icons and stuff can be rendered". Additional notes: try to make sure that label/icon placement is static from the start (reserve enough space for the final icon from the start), it would make sense to wait for 0.25 seconds before starting incremental rendering (compare to FOUC in web pages), improve caching (if nautilus has rendered /usr/bin 10 seconds ago, it shouldn't start the process from the start to get the correct icons and metadata), and finally animate (fade) between the different rendering states to make appearing icons less irritating.

Written by mikko.rantalainen the 7 Oct 10 at 07:31.

Currently opening a folder full of high resolution images take ages to get the thumbnails. Thumbnailers should be improved to support generating thumbnails with different priorities. Actually, two modes should be enough: fast and high quality.

Fast mode: get a thumbnail that somehow represents the real content (e.g. get the thumbnail from exif data or get the first pixel from each 8x8 pixel macroblock without computing the iDCT at all in case of JPEG, text only rendering of an HTML file) and generate thumbnail from that.

High quality mode: use as much CPU power as required to get the finest thumbnail that one can get. For example, a JPEG should be fully decoded, scaled with Sinc or other high quality scaler and rendered as final thumbnail. An M2TS file could be rendered as a small animation created from high quality thumbnails of 10 evenly separated screenshots from the file. A HTML file could be rendered by a browser and a screenshot should be used as an icon. In case of files in /usr/bin, a high quality screenshot would be a screenshot of UI combined with actual icon used by the application (I'm not sure these can be automatically generated at all, though -- possibly running the application in a sand box or in a virtual machine and getting a screenshot from it after letting it to get idle?).

This basically builds on Solution #8 above: render the contents of a folder without images at first, then with fast thumbnails and then with high quality thumbnails as they get ready. As a result, any folder would appear practically instantly, displayed with low quality thumbnails rapidly and rendered with high quality thumbnails if user waits for long enough (or high quality thumbnails can be already found from the cache).

Currently opening a folder full of high resolution images take ages to get the thumbnails. Thumbnailers should be improved to support generating thumbnails with different priorities. Actually, two modes should be enough: fast and high quality. Fast mode: get a thumbnail that somehow represents the real content (e.g. get the thumbnail from exif data or get the first pixel from each 8x8 pixel macroblock without computing the iDCT at all in case of JPEG, text only rendering of an HTML file) and generate thumbnail from that. High quality mode: use as much CPU power as required to get the finest thumbnail that one can get. For example, a JPEG should be fully decoded, scaled with Sinc or other high quality scaler and rendered as final thumbnail. An M2TS file could be rendered as a small animation created from high quality thumbnails of 10 evenly separated screenshots from the file. A HTML file could be rendered by a browser and a screenshot should be used as an icon. In case of files in /usr/bin, a high quality screenshot would be a screenshot of UI combined with actual icon used by the application (I'm not sure these can be automatically generated at all, though -- possibly running the application in a sand box or in a virtual machine and getting a screenshot from it after letting it to get idle?). This basically builds on Solution #8 above: render the contents of a folder without images at first, then with fast thumbnails and then with high quality thumbnails as they get ready. As a result, any folder would appear practically instantly, displayed with low quality thumbnails rapidly and rendered with high quality thumbnails if user waits for long enough (or high quality thumbnails can be already found from the cache).