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

[sgtevmckay]

Hello folks.

Here is the question: Is there a way for Circle Dock to re/draw folder graphics/Switch folder Views faster???

It is a continuing issue that even I am painfully aware of. Especially with those of us that are on very low end dual cores and single core processors.
I am on the low end of the Dual core Spectrum on my laptop and waiting for Circle Dock to Draw or re-draw graphics can be a testament to an End User's patients.
The more graphics you use on any folder, or sub-folder, level makes Circle Dock work harder and draw the graphics slower.
One solution that many have derived is to run multiple instances of Circle Dock. I find this unacceptable due to system resource constraints.
Most just; "Deal with it"

So is there a way to make Circle Dock load/switch folders faster; YES 

One of the primary slow downs of Circle Dock in drawing the graphics is in Resizing.
Resizing is where Circle Dock takes the original image and then re-sizes it to a size defined by you as an end condition.
As most custom Icon graphics are 256x256 or 512x512, this is a lot of work for Circle Dock.
Say you have a folder with 30 Icons, all of these are set in the settings to be 54x54pixels.
Well Circle Dock then has to take that huge 256 or 512 graphics and shrink it.
This takes huge amounts of time and resources.
Circle Dock also re-sizes all graphics and then shows them all almost at once.

So how to help Circle Dock Draw faster?
Reduce your graphics images to slightly larger than the size you need 

For a case demonstration; Take new graphics I introduced for the Dexpot tutorial (Project).
Each one of these graphics is 256x256 at 256k
On just 8 graphics that I use, it can take Circle Dock almost 47 seconds to load.
Now reduce the Graphics to 100X100, you are not going to be using anything that big anyways 
You will find that the images size is now 100x100 at approximately 12k -/+
That's right; You will eliminate approximately 20% of the foot print size, while shrinking the graphic before hand, this will allow Circle Dock to work less to draw/produce you graphics.
You will also find that at 100x100 Pixels, if you use icons that are 72x72 or smaller, you should still have a really good HD Graphics displayed on Circle Dock 

All this being said; be careful which graphics you reduce and to what size.
A Center graphic that is set to 100x100 will look fairly crappy from a 96x96 image.
Do not even think about reducing background images. Many of these are variable and at there limit as it is 

Even Just a change of graphics at 128x128 can significantly improve Circle Dock's draw time, and get you to your folders faster.
After having completed this experiment, I have found that Circle Dock will load my Dexpot control Graphics in about 3 to 4 seconds.
That is a lot improved over the 17 to 40+ seconds I may have waited before.
This test was done in a 32bit environment, so I expect a massive improvement in a 64bit environment

Hope this helps 

Have fun 

Regards
The Sarge

[f0dder]

Doesn't CD cache the images it uses?

This test was done in a 32bit environment, so I expect a massive improvement in a 64bit environment

-sgtevmckay (August 08, 2010, 09:20 PM)

How come?

[sgtevmckay]

Doesn't CD cache the images it uses?

-f0dder (August 09, 2010, 12:35 AM)

There was some discussion about a "Keep in memory" but this becomes heavily resource intensive
I do not know if thsi is the same or not, out side of my expertise.

This test was done in a 32bit environment, so I expect a massive improvement in a 64bit environment

-sgtevmckay (August 08, 2010, 09:20 PM)

How come?

-f0dder (August 09, 2010, 12:35 AM)

I am testing a 32bit run on a 64bit system, either way the 64bit far out perform 32bit. Why is also beyond me.
I have a friend that can also verify results in Windows XP Pro SP3

[Markham]

Doesn't CD cache the images it uses?

-f0dder (August 09, 2010, 12:35 AM)

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"!

This test was done in a 32bit environment, so I expect a massive improvement in a 64bit environment

-sgtevmckay (August 08, 2010, 09:20 PM)

A 32-bit version running on a 64-bit platform has to run in an emulator and so will be slightly slower than a 64-bit version of the software. Given two identical machines, one a 32-bit platform and the other 64-bit each running a platform-specific version, there should be no discernible difference in execution time between them.




Mark

[f0dder]

I am testing a 32bit run on a 64bit system, either way the 64bit far out perform 32bit. Why is also beyond me.
I have a friend that can also verify results in Windows XP Pro SP3

-sgtevmckay (August 09, 2010, 01:12 AM)

So, running 32bit CD on 32bit XP is also slow, or are you talking about 64bit XP? (Slightly confused since there's no SP3 for XP64).

Doesn't CD cache the images it uses?

-f0dder (August 09, 2010, 12:35 AM)

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"!

-Markham (August 09, 2010, 10:37 AM)

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

A 32-bit version running on a 64-bit platform has to run in an emulator and so will be slightly slower than a 64-bit version of the software.

-Markham (August 09, 2010, 10:37 AM)

WoW64 isn't an emulator, the 32bit code runs natively at full CPU speed - some calls need thunking between 32- and 64bit code, but normally this isn't a problem (e.g. 32bit games run perfectly well on 64bit Windows). There's a few pathological cases, though, and if you're using GDI+ that might be it - Foxit Reader (used to?) slows to a crawl when rendering complex PDFs, so much that it's actually faster to render them in a 32bit virtual machine instead of running native. But for most stuff you can barely notice a speed hit.

Given two identical machines, one a 32-bit platform and the other 64-bit each running a platform-specific version, there should be no discernible difference in execution time between them.

-Markham (August 09, 2010, 10:37 AM)

You should see a slightly larger memory footprint from running a 64bit version, though

[sgtevmckay]

Windows XP Pro SP3

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

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?)

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)

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)

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)

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)

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)

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)

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)
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  
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...