We implemented a number of QImage/QPixmap caches for our generated icons in KDE - here's a link to the Qt4 C++ sources of one in case you want to adapt it for CL:
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kimagecache_8cpp_source.html
Thanks for that suggestion
Unfortunately, caches are not going to work in this case.
In order for me to dynamically update the star count-per-star-type, the star icon with the count of stars in the jump table is generated dynamically, according to the number of stars of that type registered for that particular system in the jump table. This is done for each type of star registered for that system, and for each jump in the table.
If a user goes to an earlier jump, to - say, correct the star types and amounts for that system - upon each click to either increment or decrement a star type, I have to rebuild the one or more "count icons" in the jump table for that jump/system.
Now, I could probably implement some kind of Clever Caching Thing, and keep a cache of previously generated icons - but then I've got even more problems than I have currently. And to be frank, it's probably over-engineering a solution to the problem.
I've just thought of another possibility. Rather than dynamically generating a pixmap, I could probably do what I do with the clicky-input stars on the right-hand side. That is, I cheat and use QToolButtons for those, set an appropriate pixmap, and bung the text to the side or below. But I think I tried that approach originally, and for some reason the text wouldn't render in the centre of the QToolButton when it had a pixmap set, so I'd have to compromise and have the count underneath or to the side of the button. Since I think having a star count in the centre of the icons looks cool, and also saves space, that's why I settled for the dynamic generation of pixmaps in the end.
I'll have another go at using QToolButton again - my memory of all this is hazy since I got the current system working - but I'll have to try something to speed up the initial jump table population eventually. Once you get to a couple of hundred - or thousand - jumps, all with star types registered in each, initial loading after starting CL gets slow. And I've ran out of tricks on the Python side of things to speed that up
If I can get text rendering properly in a QToolButton with a pixmap set, then this would probably speed things up a lot. Then again, I'd have the problem of keeping track of thousands of dynamically generated QToolButtons, all needing a unique name. So we're back to square one; what's better - dynamically generated pixmaps bunged into a custom QWidget then shoehorned into a QTableWidget row, or trying to keep track of potentially thousands of QToolButtons?
After typing that lot out, I've kind of came to the conclusion that short of rewriting CL in C++, there's no awesome way of doing this other than what I've already done
(Plus, my C++ is rusty to the point of uselessness).
There is another possibility, which is to compile the Python into C using Cython then compile the C to an exe. I've done this before, and even
wrote in StackOverflow on how to do it. But for CL it's going to be a PITA - and I've only ever done that for Linux, not Windows.
