wishlist: Progress meter for large SVG files

[mycae]

Is it possible to have scour support some kind of verbose output mode, where information such as "progress" is provided?

Thanks!

[codedread (codedread)]

This is a good suggestion - can you provide any more details on this requirement?

Would it be enough to just print out what step scour is at some level of detail, ie

Step 1 of 15: Removed unwanted namespaced elements
Step 2 of 15: Removed unwanted namespaced attributes
Step 3 of 15: Removed redundant namespace prefixes
Step 4 of 15: Removed unnecessary style properties and moved to XML attributes
Step 5 of 15: Converted colors
:

Note that even with the above, each step could take an unknown amount of time, since the structure of each file determine how long it will take, and each file is different.

Would it be useful for this to be a non-default mode, ie something you have to explicitly enable (--verbose) or do you recommend this to be the default? I would have to use stderr to print out this information as scour may be printing to stdout if no -o argument is supplied.

[mycae (mycae)]

> Would it be enough to just print out what step scour is at some level of detail, ie

Well, where I was coming from was that I had generated some 2D plots with scilab, which, when exported to SVG are ridiculously huge (1.8MB), however I want to keep them at print quality, so I ran scour. I came back three hours later and it was still running.

If you want super-awesomeness, a wget style 0[======> ]100% meter would be perfect, which is something along the lines of:

Step (1/15) 0 [===================> ] 100%

however I am not sure how portable this is across mutliple terminals. At the very least your suggestion would be nice.

I would suggest that this need be explicitly enabled, and would be written to stderr. Does this work on windows though? Do they have a separation of stdout/stderr ? For windows you may need to force the usage of -o.

Thanks!

[Louis Simard (louis-simard-deactivatedaccount)]

Windows consoles do have stderr.

Your suggestion could be done portably, if done like codedread suggests:

[1/15] Removing unwanted namespaces (no newline)

then

(Done in X.XX s) (newline)

etc. until the end of the steps.

I did a lot of optimisations in time for Scour in lp:~louis-simard/scour/rework, i.e. it runs much faster for a variety of files now. This suggestion could still have some use when the files are huge like the one you processed, but less so. Do you still have the file you processed and wanted a progress bar for?

[mycae (mycae)]

Sorry about the delay, I meant to do this, but only came across this again today.

[Louis Simard (louis-simard-deactivatedaccount)]

So I just ran the latest Scour on your file with the 'time' utility, on a 2.6 GHz AMD processor, with DDR2 800 MHz, running 32-bit Linux.

real 55m54.557s
user 53m19.344s
sys 0m19.781s

If the specs of my computer and yours are comparable (core count aside, because Scour is a single-threaded program), the latest Scour is 3 times faster than the version you used. But you've hit a hard spot of Scour's with that file, and perhaps this should be optimised first before considering adding a progress option :)

I concentrated on optimising Scour's path optimisation to make it faster, and didn't pay a lot attention to polygons. That file is full of them.

So I've opened bug 616150 for the optimisation of polygon optimisation. Please follow that bug if you're interested in getting progress on that. This thread will continue to be about progress reporting.