Thicker lines

[CobraA1]

Right now, the lines in the defrag view are pretty thin - especially on a high resolution display. This makes placing the cursor over a specific file (such as an unmovable file) pretty difficult.

Would it be possible to have an option to make the lines thicker?

[Darlis]

Try clicking on the file you want to examine multiple times. This will zoom into the diskmap and make the file bigger.

[jeroen]

Would it be possible to have an option to make the lines thicker?

It has been suggested many times before, and I have looked at it many times before and it's still on my wishlist, but it's not as easy as it sounds. The biggest problem is that it would make the display considerably slower. Another thing is that I cannot decide what color to show in blocks on the display that contain a mix of items: fragmented, movable, selected, processed, and gaps. At the moment there are 20 different possible colors for a single cluster.

[CobraA1]

Well, the display should be independent of the actual defragmentation process - or I hope it is. The speed of updating the display should not be affecting the defragmentation, and should not be a major concern.

If I am wrong, and if the defragmentation process waits for the display to update, and there are indeed performance issues with the display, then I have a very good idea of why small files are taking so long to process  .

In addition, drawing itself shouldn't be that much of a concern: On modern hardware, the drawing process itself should be fast. The days of taking a large fraction of a second to update a display should be long behind us, unless you're trying to run it on a pre-Pentium CPU.

"Another thing is that I cannot decide what color to show in blocks on the display that contain a mix of items: fragmented, movable, selected, processed, and gaps."

I'm not necessarily saying divide it into blocks - I'm saying render each "point" as a rectangle at twice the height or higher.

Another way of thinking about it is to render at half the height, and just draw each pixel twice.

Even now, it is possible to resize the display to a small size where each pixel may represent more than one item. How do you resolve it currently? I'm not saying change that part of the process.

Try clicking on the file you want to examine multiple times. This will zoom into the diskmap and make the file bigger.

That kinda helps, but may take many times for small files to become more than one pixel thick, and is pretty much a kludge rather than a real solution.

[BloodySword]

The Display is updated with an interval of ca. 250 ms. The display is also updated on any scrollbar scroll or change event.

[jeroen]

Well, the display should be independent of the actual defragmentation process

Sorry, I have no time (and am not in the mood) to explain the many fallacies in your arguments.

[CobraA1]

Sorry, I have no time (and am not in the mood) to explain the many fallacies in your arguments.

In other words, it's not independent. Right, okay. That does explain a lot.

Are you using GDI or GDI+?

[BloodySword]

GDI+ would draf antialiased. It is possible to say it should not but I think it uses GDI, because for compatibelity with Windows 2000 wich does not have GDI+ installed.

[CobraA1]

Yeah, well GDI and GDI+ are known to be slow. They were designed to draw OS widgets as far back as Windows 3, and were never really suitable to real time displays. They have strange limits in the number of objects. That, plus they totally changed the way graphics worked in Vista (WPF and Direct2D), and didn't bother to re-implement hardware acceleration in GDI until Windows 7 (and even then, it's still very limited acceleration).

So - I can understand the frustration. It's a common API, but not the best for drawing complex or real time graphics.

[BloodySword]

On new hardware, it would not make sence to acclegate such display things...

Inkscape is crashing (on windows) when it's reaching the limit of 10 000 GDI objects. It's very frustrating.

[CobraA1]

On new hardware, it would not make sence to acclegate such display things...

Despite advances in CPU technology, it's still the case that GPUs are generally far more powerful at rendering graphics, because they too have been advancing in technology. If an application is choking on graphical performance, it would gain a boost from a GPU.

Microsoft's new APIs for desktop rendering (Direct2D and WPF) are hardware accelerated - apparently Microsoft disagrees with that assessment.

I'm not saying that an application like this should be moving to Direct2D or WPF (it would limit compatibility), but just be aware of what's out there.

There are many way to draw a graphic like what MyD uses, and I guess the author has chosen a method that is difficult to translate into a different form.

[BloodySword]

Perhaps in the future, when Windows 2000 and XP is used so seldom that it doesn't matther anymore Jeroen could think about using Direct2D or WPF, where WPF catches not really on. Eventually WPF will be dropped.

[CobraA1]

Ultimately it's up to Microsoft whether WPF is dropped. IMO GDI's own days are limited.

[BloodySword]

WPF is used in Windows Media Center, isn't it?

Okay GDI is a brownfield wich we should get away like IE6. But like with IE6 ist is not easy.
And MyDefrag won't slow down with GDI, because the display is only updated every 250 ms
since the last two beta releases of MyDefrag. I don't remember clearly when it was changed.
Before that, MyDefrag updated the display for every file.

[Kasuha]

Would it be possible to have an option to make the lines thicker?

It has been suggested many times before, and I have looked at it many times before and it's still on my wishlist, but it's not as easy as it sounds. The biggest problem is that it would make the display considerably slower. Another thing is that I cannot decide what color to show in blocks on the display that contain a mix of items: fragmented, movable, selected, processed, and gaps. At the moment there are 20 different possible colors for a single cluster.

I have found pretty annoying problem with MyDefrag's diskmap in Windows 7. For some reason, the cross cursor in W7 is two pixels wide and that means I am not really sure what am I pointing at in the diskmap.

So far MyDefrag does not seem to care much about colors of individual pixels. Out of 20 possible colors you talk about each pixel gets just one every time even if the pixel covers multiple files and gaps. I believe this approach can be kept in the first step of zooming pixels in the diskmap - zoom up to say 3x3 could be implemented as a simple "nearest neighbor" stretch of current diskmap (i.e. it is drawn as if the window was two or three times smaller in each direction, then stretched - or drawn stretched directly by proper recalculating pixel positions and drawing rectangles instead of pixels and lines).