There is a way to stick multiple resolutions in one .ico file.  For example, I've got one that has 7 images in it:
256x256x32, 48x48x32, 32x32x32, 16x16x32, 48x48x8, 32x32x8, 16x16x8

I'm not sure if there is software out there that builds multiple images for a .ico file on the fly given one image, but it would be handy in this case.  I've been making individual icons and slapping them together after the fact.

If you use one of those icon files for your build, it should bring over all of them.  If you look at VLC, for example, there are a number of icons within it, one of them being 256x256x32.  Keep in mind that if you do a multi-resolution icon file, the first icon in the file is the one that the preview pane will lock onto.

If it does work out for you, i.e. you can get multiple resolutions into one .ico file, then that would be way easier than the way I'm doing it now.  As it is now, I take each version of the icon and slap it together with a hex editor so that all of them are in one file.  Windows will pick the right icon for the right situation.  For example...

User is running a 32-bit desktop (aren't we all now?):
Standard desktop icon size is 48x48: Windows reads the 48x48x32 icon
Right click and select properties.  The icon inside the dialog next to the file name input box is the 32x32x32 icon and the titlebar of that dialog is the 16x16x32 icon.

Theoretically, you could have totally different icons for each resolution and optimize the icon for what looks best at each resolution.  If the user is running a 16-bit desktop (maybe a really old XP machine), then Windows will load the appropriate 8-bit icon.  The only color depths I've seen so far are 1, 4, 8, 24, and 32 bit.  I don't think anybody does less than 8-bit anymore, and even that is probably falling off.

If the program you're going to use refuses to put multiple resolution images in one .ico file and instead puts them in a .icr file, I can show you how to work from there to get what you need.

EDIT: I just took a look at logo.ico from 20110327, because I was interested in what you've got.  I actually don't use this miner since I'm running CUDA.  It seems that there are already 6 images in this file, all 32-bit.  16x16, 32x32, 48x48, 64x64, 128x128, and 256x256, in that order.  Whatever you were using before seems to do the job.  The only thing you would do different is if you want to create different images for different resolutions.

Looking at this site indicates to me that there's no way to avoid this behavior using ICO files.

EDIT: Got this taken care of, I just pull the 16x16 icon out of the icon bundle and explicitly give that one to the taskbar. I also had to hand-edit the 16x16 icon since it was giving translucent pixels and apparently those actually mean "be really dark". After taking those out, it looks fine now

Well, I'm glad you were having fun

You mentioned you don't use the miner because you use CUDA - would you be interested in testing CUDA support if I were to integrate an existing CUDA miner into the GUI? From the poll in the thread there seems to be reasonable demand for it, but I don't have any CUDA capable hardware around.

If you get the .ico file extension plugin for photoshop, you can save multiple sizes and bit-depths to the same file doing it one-by-one. I've made quite a few icons like that.

after installing opencl sdk, my nvidia card stopped working,

The console view show
Wish I could press it... what should I do ? Is there a poclbm flag to bypass this and force cuda ?

nVidia drivers come with OpenCL support built-in.  Installing AMD's OpenCL SDK is not helpful.  That SDK is made for AMD cards and will only add clutter to your machine.  You're going to want to remove that.  Also, poclbm (Python OpenCL Bitcoin Miner) does not run CUDA code, it runs OpenCL code.  You'll be selecting the platform that nVidia has set up to run OpenCL code on CUDA capable hardware.  This GUI that Kiv is writing up will have CUDA support in the future, but it only uses poclbm at the moment.  CUDA and OpenCL run fairly close to the same level of performance on nVidia hardware, but I have seen about an 8% performance benefit using a true CUDA miner over an OpenCL miner.  If this GUI gets CUDA support, I'll be willing to try it out to see if I get the same level of performance.  Mind you, I've done some tweaking of CUDA parameters to get to the performance I've got.

It works on my 8600m GT. but i get lower khash/s and my computer is slower... So reverting back to opengl .

If you don't feed the CUDA miner specific gpugrid and gputhreads parameters, it will do a benchmark of all of the available options to find the best one.  Either due to a bug or driver issues, some of your first couple of runs of the CUDA miner may be less than you could get.  Sometimes if you leave your system idle for about 60 seconds, then you get better speeds.  Sometimes, you would have to run it immediately after closing it to see the best speeds.  It's somewhat random.  If you do see one instance of it running the fastest, take note of the last pairs of numbers that show up.  For me, the best pair of numbers ended up being (128,128).  They'll show up in the order (gpugrid, gputhreads).  Otherwise, you could just run the miner yourself, constantly varying the inputs until you see the greatest average mining speed.  The first report of the hash speed will be lower than all of the others, so give it some time.  Also, for the large majority of nVidia cards, your ask rate should be larger than the default.  If you get less than 40 Mhash/s, this should be 10 seconds (10000 ms) or greater.  Everybody has a different theology for the interval between getwork requests, so if you mine in a pool, you may have to PM a pool operator for the settings that they would like you to use.  They'll need to know your hash rate.  As far as system slowness, there's an aggression setting you can raise or lower to change the responsiveness.


I haven't had the time to run it, yet.  I'll be doing that sometime within the next 24 hours.  I'm glad to test it out for you and offer any suggestions I can, since I've been toying with these miners for some time.


Yeah, I can't see how you would be able to fix this other than making a specific form for each miner.  As far as I know, puddinpop's RPC OpenCL miner and m0mchil's Python OpenCL miner yield pretty close to the same hash rate on a majority of hardware.  I don't think there will be too much of an outrage if puddinpop's OpenCL miner gets left out, but it would still be a little bit of a headache to set up hardware lists for each miner (OpenCL vs. CUDA).  The RPC CPU miner that does not have the -4way suffix runs the same code as the bitcoin client, if I remember correctly.  That one can probably be ignored, as well... maybe.  Also, CUDA has this weird behavior of making my secondary card be GPU 0 and my primary be GPU 1.  Just thought I would pass that along.