Rockbox

Tasklist

FS#6310 - Progressbar while deleting folders.

Attached to Project: Rockbox
Opened by blue_lizard (blue_lizard) - Thursday, 09 November 2006, 21:59 GMT
Last edited by Jonathan Gordon (jdgordon) - Sunday, 05 August 2007, 10:25 GMT
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

This patch introduces an progressbar while the device deletes folders/files.
It should work on all devices that have HAVE_LCD_BITMAP.
If a wps with an grafical progressbar is used it will use it for this too if not a simple bar will be presented.
Of course an % counter is also present.
Devices that don't have HAVE_LCD_BITMAP the normal delete routine will be used.
Has been tested on H300 hardware and sim.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Sunday, 05 August 2007, 10:25 GMT
Reason for closing:  Out of Date
Comment by Dan Everton (safetydan) - Friday, 10 November 2006, 09:22 GMT
Seems like a lot of code for not much extra value. From a quick skim, it seems you count the number of files, then do the deletion. Doesn't this make deleting twice as slow? Maybe an "infinite" progress bar might be a better choice if you really want some sort of indication of progress.
Comment by blue_lizard (blue_lizard) - Sunday, 12 November 2006, 00:45 GMT
Yes from a quick skim it might seem so.
I am not only counting the files i am also counting the bytes. So the progress bar is quite accurate and is the exact opposite of your proposed "infinite" progress bar. I didn't want some sort of response, i want an accurate response one can rely on.
Is seems that on your systems something is totally wrong because deleting files on your fat file systems is so fast or traversing directories is way too slow. I made following measurements on my h340 (hd spin up times are included).
Deleting 3565 M bytes (571 files)
Without patch: ~75 Seconds
With patch : ~80 Seconds
The relation may change if one deletes fewer files.
Furthermore the code is of course bigger than before but 1/3 of code is the original routine that is used in systems that don't have an graphical display. This code is not compiled in if it is not used and vice versa.
Comment by Dominik Riebeling (bluebrother) - Sunday, 12 November 2006, 08:11 GMT
for your measurements, had you dircache enabled? I wouldn't be surprised if this would be way slower with dircache disabled.
Comment by Robert Kukla (roolku) - Sunday, 12 November 2006, 15:02 GMT
I like the progress indicator very much - an activity indicator wouldn't give much more information than the hard disk activity light already gives.

Could it possibly be extended and used for "paste" as well which is another time consuming operation.

BTW: there are two missing prototypes in the code:

onplay.c: In function `remove_dir_execute':
onplay.c:473: warning: implicit declaration of function `gui_bitmap_scrollbar_dr
aw'
onplay.c:479: warning: implicit declaration of function `gui_scrollbar_draw'
Comment by blue_lizard (blue_lizard) - Tuesday, 14 November 2006, 22:07 GMT
@bluebrother
as far as i remember dircache was disabled because it is default in an new installation. Because i am not absolutely sure anymore i made some new test.

original without dircache: ~78s
original with dircache: ~75s
patched without dircache: ~86s
patched with dircache: ~82s

again with 3565 M bytes (571 files)

@roolku
i am already working on the progress bar for copying files

The problem with the two unresolved symbols can be circumvented if i would include scrollbar.h.
Unfortunately this is not possible at the moment because the symbols HORIZONTAL and VERTICAL are defined in recorder/widgets.h and in gui/scrollbar.h
The original onplay.c already includes plugin.h which includes widgets.h. and therefore can't include scrollbar.h at the same time because that would redefine the symbols.
This is a problem the core developers have to solve. At the moment we have to live with that.
Comment by blue_lizard (blue_lizard) - Monday, 20 November 2006, 22:30 GMT
Sorry i haven't had much time.
For the people that still are interested, if any:
Progress bar while deleting files and progress bar while copying files.
Comment by Robert Kukla (roolku) - Monday, 20 November 2006, 23:03 GMT
Looks very good!

Could I suggest one improvement? Could you display the directory that is being deleted/copied? Not every individual item, just the entry that was selected in the file browser. Sometimes during a long delete I panic that I might have selected the wrong directory and such a display would re-assure me and prevent me from frantically trying to abort the process. :)
Comment by Peter D'Hoye (petur) - Friday, 01 December 2006, 20:51 GMT
Some remarks:

1. As far as I can see this code doesn't use dircache to build the summary so that's why dircache doesn't seem to make much difference in the above timings.
2. This seems a BIG overkill to me. I was thinking of displaying the dir being deleted as info, not something big as this. FYI, I had no choice but to move the file/dir property to a plugin because of the wasted binary size. If file operations could also move to a plugin this would already be much better.
Comment by Oleg G (MadCow15) - Saturday, 24 February 2007, 18:38 GMT
Patch broken against newest SVN. Seems like the big menu changes screwed it up.
Comment by Peter D'Hoye (petur) - Thursday, 07 June 2007, 09:04 GMT
My vote to this task is actually a negative one.... I'll never click on links again unless I understand it ;)

Loading...