Closed GoogleCodeExporter closed 9 years ago
wrong file..
Original comment by reiter.christoph@gmail.com
on 4 Mar 2009 at 1:01
Attachments:
put it into utils and replace all other thumbnail loading code with it.
Original comment by reiter.christoph@gmail.com
on 6 Mar 2009 at 6:32
Attachments:
and again
Original comment by reiter.christoph@gmail.com
on 6 Mar 2009 at 7:55
Attachments:
Original comment by steven.strobe.cc@gmail.com
on 15 Mar 2009 at 1:23
I tested by adding a call to gtk.main_quit() at the end of library.songs.scan,
so
that QL would terminate immediately after scans completed. I ran this under
cProfile
(python -m cProfile -o output.pstats quodlibet.py) three times without the
patch,
once with the patch to generate the thumbnails, and three times with the patch
and
the thumbnails together.
There was no significant difference in the CPU time of the program between the
first
three runs and the last three. There may be a difference in IO performance, but
since
the program was run multiple times in a row this difference would be obscured
by the
cache. Still, the patch caused no ill effects, and does what it claimed to do.
Adding
a test would likely improve the likelihood of the patch making it upstream,
though.
It's worth noting that more than 20% of the CPU time was spent in the method
quodlibet.util.make_case_insensitive and the *millions* of calls it subsequently
makes to str.lower and str.upper. Eliminating that method call one way or
another is
the easiest way to boost startup performance on non-IO-constrained systems.
Original comment by steven.strobe.cc@gmail.com
on 16 Mar 2009 at 1:53
You're probably right.. I expected more from this.
I also added gtk.main_quit, but at the end of loading the covers..
so I probably wasn't measuring the whole startup time.
Only (real) good thing about it is, that we could use bilinear filtering
instead.
That would give better image quality at the same speed (like nautilus does).
I will have a look at that tomorrow.
Original comment by reiter.christoph@gmail.com
on 17 Mar 2009 at 9:44
New one:
- Did some time measuring: no improvement..
- But, the albumart thumbnails look much sharper and the aspect ratios are
correct.
Original comment by reiter.christoph@gmail.com
on 17 Mar 2009 at 6:55
Attachments:
uhh... the last one had an import error.. the thumbnails weren't used at all :P
I did some testing with cProfile:
before: 339 0.076 0.000 10.334 0.030 albums.py:446(__scan_covers)
after: 339 0.058 0.000 4.079 0.012 albums.py:446(__scan_covers)
339 covers, about 800x800 resolution each -> 60% speedup + better image quality.
Original comment by reiter.christoph@gmail.com
on 25 Mar 2009 at 9:07
Attachments:
[deleted comment]
Added a few testcases and rounded thumbnail corners. (#2.. argh..)
Original comment by reiter.christoph@gmail.com
on 25 May 2009 at 1:00
Attachments:
Original comment by steven.strobe.cc@gmail.com
on 18 Jun 2009 at 8:16
Very nice. Suggestion: use these rounded thumbnails in the notification
plug-in.
Original comment by eric.pot...@gmail.com
on 20 Jun 2009 at 2:05
Original comment by steven.strobe.cc@gmail.com
on 28 Jun 2009 at 4:23
Album view:
- only load covers for visible rows.
- don't load covers if the cover column is invisible
Original comment by reiter.christoph@gmail.com
on 11 Aug 2009 at 1:02
Attachments:
- queue_resize the right column after toggling the covers.
- eliminate some useless copool action.
- increase scan delay to 50 msec.
Original comment by reiter.christoph@gmail.com
on 12 Aug 2009 at 10:59
Attachments:
- remove pending covers which are not in range any more... silly me
- even faster now (especially if uncached) :)
- sorry for spamming here all the time..
Original comment by reiter.christoph@gmail.com
on 13 Aug 2009 at 9:18
Attachments:
speaking of spamming... forgot one check
Original comment by reiter.christoph@gmail.com
on 13 Aug 2009 at 9:35
Attachments:
This issue was closed by revision a0fc6b1ba0.
Original comment by steven.strobe.cc@gmail.com
on 23 Aug 2009 at 4:34
Original issue reported on code.google.com by
reiter.christoph@gmail.com
on 4 Mar 2009 at 12:23Attachments: