Welcome Guest.   Make a donation to an author on the site November 23, 2014, 03:50:29 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Learn about the DonationCoder.com microdonation system (DonationCredits).
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: Can I speed up CD's Folder switching/Redraw (CD Quick Tip)  (Read 3418 times)
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« on: August 08, 2010, 09:20:21 PM »

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  Cool

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  Kiss

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  Wink

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  Cool

Have fun  Thmbsup

Regards
The Sarge

Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #1 on: August 09, 2010, 12:35:05 AM »

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
How come?
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #2 on: August 09, 2010, 01:12:39 AM »

Doesn't CD cache the images it uses?
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
How come?
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
Logged
Markham
Honorary Member
**
Posts: 404


see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #3 on: August 09, 2010, 10:37:49 AM »

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

This test was done in a 32bit environment, so I expect a massive improvement in a 64bit environment
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
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: August 09, 2010, 11:29:15 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
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?
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

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.
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.
You should see a slightly larger memory footprint from running a 64bit version, though Wink
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #5 on: August 09, 2010, 01:23:31 PM »

Quote
Windows XP Pro SP3
Not the 64bit

Quote
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.
Quote
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.
« Last Edit: August 09, 2010, 01:26:08 PM by sgtevmckay » Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #6 on: August 09, 2010, 01:54:05 PM »

@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.
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 smiley

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' smiley

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.
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.
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"
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 Wink (no offence meant).
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #7 on: August 09, 2010, 02:43:51 PM »

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

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  Sad
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  ohmy
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  embarassed
« Last Edit: August 09, 2010, 02:47:43 PM by sgtevmckay » Logged
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.044s | Server load: 0.29 ]