DonationCoder.com Software > Circle Dock

Can I speed up CD's Folder switching/Redraw (CD Quick Tip)

<< < (2/2)

sgtevmckay:
Windows XP Pro SP3

--- End quote ---
Not the 64bit

Quote from: Markham on Today at 08:37:49
Quote from: f0dder on August 08, 2010, 22:35:05
Doesn't CD cache the images it uses?
No it doesn't although this is something the original author planned on doing. However caching the images would be quite expensive in terms of memory which goes against what I believe the program is and should do. Circle Dock is a utility and should be lean and mean in terms of memory footprint and resources. I am definitely not in favour of "bloatware"!
Calling caching "bloat" isn't deserved, imho - bloat is about useless functionality or wasting memory (or other resources), caching is a speed/memory tradeoff. Caching 128 images (more than most people will be using?) of 128x128x32bpp (larger resolution than necessary?) would take ~8meg of memory... hardly a lot, even on low-end machines. OTOH, caching the images could speed up the program noticably on low-end machines (not wasting CPU cycles or HDD access to decode images), and wouldn't require users to re-scale their images manually. It's not terribly hard to make a configurable cache smiley
--- End quote ---

Two kicks in the shorts here.
For some reason I have yet to properly ascertain, Most Custom Icons come in either 256x256 or 512x512.
Some weird belief in HD graphics and solution reduction where the graphic is reduced in programs such as ObjectDock, Rocket Dock, Circle Dock and so on.
Remember folks this is only a suggestion.
In circle Dock it is almost necessary to have a background at 750X750 or greater.
An all other graphics should be at 100x100 to 128x128. This is to compensate for when the graphics moves from the ring to the center.

@f0dder; Ultimately I understand the point that you are making, but even in a round about way, you have just suggest image reduction prior to use.
Caching 128 images (more than most people will be using?) of 128x128x32bpp (larger resolution than necessary?)
--- End quote ---
Since most graphics are incredibly larger than this, and mostly I think for "Show and Tell" and "Better Detail" that is never noticed at a level of say; 56x56.
I find that most End Users, myself included, only unpackage and install the Image, and never consider things like size reduction, or even location of the graphic.
I have found in several products that graphics are rendered much faster, regardless of size, if the graphics is placed in the Locaized Path.
ie. Icons store in the Circle Dock Icon Folder are accessed faster than in my Graphics folder that is not in a localized path to the Circle Dock folder.

In my test group I have found that Circle Dock 64bit operates faster that Circle Dock 32 bit.
regardless if CD 32Bit is in a native 32bit or 64bit environment. I have no idea why.
Is the systems Foot print of the 64bit larger; Yes, but only by a few "K"
Also not typical, but is happening Circle Dock 64bit is a smaller package than the 32bit install package.
This is extremely out of any norm.

Ultimately this was nothing more than a suggestion, a Quick Tip, and yes requires work.

f0dder:
@f0dder; Ultimately I understand the point that you are making, but even in a round about way, you have just suggest image reduction prior to use.-sgtevmckay (August 09, 2010, 01:23 PM)
--- End quote ---
Partially true - keeping the images cached after resize also means you don't have to read disk on subsequent uses, nor process the files. Granted, it doesn't take that much CPU power to decode small PNGs, and even less for ICOs (unless they're large vista-style icons, which iirc uses PNG compression). Still, a BitBlit from memory is a lot faster than reading, decoding and BitBlitting :)

And then there's the point of saving the user from doing the size reduction. If you've got some nice large icons which you might be using for other purposes as well, it's a bit annoying having to keep both the large icons + downscaled versions around. Even if you only need the downsized ones, not everybody knows how to do batch resizing of images. Just sayin' :)

I have found in several products that graphics are rendered much faster, regardless of size, if the graphics is placed in the Locaized Path.
ie. Icons store in the Circle Dock Icon Folder are accessed faster than in my Graphics folder that is not in a localized path to the Circle Dock folder.-sgtevmckay (August 09, 2010, 01:23 PM)
--- End quote ---
That sounds pretty darn weird!

In my test group I have found that Circle Dock 64bit operates faster that Circle Dock 32 bit.
regardless if CD 32Bit is in a native 32bit or 64bit environment. I have no idea why.-sgtevmckay (August 09, 2010, 01:23 PM)
--- End quote ---
That does sound weird - I wouldn't be all that puzzled about 32bit performing somewhat slower on a 64bit system, given the GDI+ experiences mentioned above, but since CD isn't an especially CPU-intensive program this does sound queer. When is the speed difference felt? Upon loading images, or at display time when rotating etc?

Is the systems Foot print of the 64bit larger; Yes, but only by a few "K"-sgtevmckay (August 09, 2010, 01:23 PM)
--- End quote ---
Yes, it isn't much for most programs - code doesn't bloat by all that much, and for normal programs data won't blow up much either. Was meant a bit tongue-in-cheek since Markham seems a bit obsessed with memory bloat ;) (no offence meant).

sgtevmckay:
In my test group I have found that Circle Dock 64bit operates faster that Circle Dock 32 bit.
regardless if CD 32Bit is in a native 32bit or 64bit environment. I have no idea why.-sgtevmckay (August 09, 2010, 01:23 PM)
--- End quote ---
That does sound weird - I wouldn't be all that puzzled about 32bit performing somewhat slower on a 64bit system, given the GDI+ experiences mentioned above, but since CD isn't an especially CPU-intensive program this does sound queer. When is the speed difference felt? Upon loading images, or at display time when rotating etc?
-f0dder (August 09, 2010, 01:54 PM)
--- End quote ---

The difference in mainly in initial build at start up, draw and/or Redraw.
Apparently with Circle Dock set to an FPS of 60 in both 32bit and 64bit appear to run "Spin" very smooth.
Even if the 32bit is run in a 64bit environment.
The problem is centered around the Build time for graphics when a folder, or sub-level, is switched to.
Switching from a primary level to a sub-level (Folder), Both 32 and 64 bit containing the same graphics (Size and amount; in this case eight 256x256 at 256k) The 64bit environment will draw the necessary graphics significantly faster That Circle Dock 32bit running a 32bit environment or in a 64bit environment.
Now Markham has expressed to me that Circle Dock running in a natural 32bit environment (ie XP Pro) should have no difference when compared to Circle Dock 64bit running on Windows 7 64.
I also understand that "Mileage" may vary, greatly depending on Ram and CPU Speeds.
This may be the key point as, as far as I know, GDI and GDI+ are supported by Systems resources and are not, or cannot, be handed off to a graphics processor/accelerator.
If this is the case, then the End User is greatly at the mercy of his core system resources .
A simple example.
My laptop (HP Craptop) has a T3200 (Intel 2.0G with 512x2 L2 cache), 4 Gigs RAM at 800Mhz, Intel 4500 graphics onboard. Shared Memory  :(
My Desktop has AMD 965 QuadCore, 16 Gigs DDR2 1066, nVidia GTX 260, Asus MoBo, All the trimmings (Built Myself and it is Evil!!! Mwwhahahhahaaaa) :Thmbsup:
Both Running Windows 7 Home Premium 64bit.
Circle Dock runs so efficiently on the Desktop, that I do not even have to consider graphics resizing and other techniques to speed up the drawing process.
That being said; A reduction in Graphics size to 128x128 has also proven a significant speed up on the quadcore desktop.
I click a button and The new folder is there  :o
On the Craptop, there is a significant wait, but with the reduced graphics size, it will almost (not quite) compete in drawing with the quadcore when it uses full size graphics

Now my friend who has a home built Intel 8400 CPU, 2Gigs of Ram 1066 DDR2, NVidia 9800 GTX, on an MSI MoBo has found that his draw time are really not much better than I get running Circle Dock 32 bit on my 64bit system.
His OS is Windows XP Pro w/SP3
Now if he previously reduces the graphics size, then Circle Dock 32bit running on his 32bit system will draw as fast as my QuadCore with Circle Dock 64bit on Windows 7 64
Although his system may not have the latest and greatest stuff on it, it is still a top notch system when it comes to performance.

Apologies if I am rambling  :-[

momashi:
Oh my god, you guys are awesome!!! I had circle dock running the main dock and two dock folders under one instance. It was excruciating! I'm running a quad core with a crazy buffed up GPU that can run most 2015 games at Ultra without a sweat but I was getting all these lags when I switched from one dock folder to another... It was really distracting.

I've optimized the icons and background as Markham suggested and did multiple instances, it went from 4 seconds of lag to switch from one dock to another to none at all!  I've even setup the different docks with dock items that link to Autohotkey executables that can start the other docks/instances in order to switch between them seamlessly.

Thanks for that!

PS - Just a note for anyone reading this in 2015 and on. This post is really old, be aware that the OP's statement about multiple instances taking up too many resources doesn't really apply with today's machines (even if they're really old). From what I observed in Process Explorer, each instance of CD takes no more then 4mb of ram (though it seems to use alot of virtual memory). 5 tabs in Google Chrome take up 140mb of ram. Sometimes Chrome can take up to 800mb ram. That's like 30 to 200 time more RAM then each instance of CircleDock. One can easily run 10-15 instances without putting a dent on resources...

Navigation

[0] Message Index

[*] Previous page