DonationCoder.com Software > Circle Dock

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

(1/2) > >>

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  :Thmbsup:

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

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  :Thmbsup:
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  8)

Have fun  :Thmbsup:

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)
--- End quote ---
How come?

sgtevmckay:
Doesn't CD cache the images it uses?
-f0dder (August 09, 2010, 12:35 AM)
--- End quote ---
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)
--- End quote ---
How come?
-f0dder (August 09, 2010, 12:35 AM)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
You should see a slightly larger memory footprint from running a 64bit version, though ;)

Navigation

[0] Message Index

[#] Next page