[4.2.1] Screensaver blue screen or extremely slow rendering

[jeroen]

I can also confirm that on some configurations, the screensaver-version is much slower than the normal executable

I have just learned that screensavers are run by Windows with the "idle" process priority. I think this explains why the screensaver can be slow on some computers.

[PoP]

I have just learned that screensavers are run by Windows with the "idle" process priority. I think this explains why the screensaver can be slow on some computers.

I doubt this is the answer.
One of my machines has a minimalistic configuration with
the least possible services and background tasks, no internet/network.
And the analysis stage of the screensaver is very slow.
It cannot explain either why on another machine (with an ATI graphic chipset)
the screensaver is very slow (and eventually crashes) without the status bar
while it runs at normal speed with the status bar on.
At last the fact that a screen saver runs at the idle priority level should not
make much difference since it's supposed to run while the system itself is idle.

I noticed that despite the fix in 4.2.4 the status bar of the screensaver still
does not display the percent analyzed (nothing after "processing disk C:").

Many thanks anyway Jeroen and all the best. The regular exe with the scheduler
will do the job.

[jeroen]

I doubt this is the answer.
One of my machines has a minimalistic configuration with
the least possible services and background tasks, no internet/network.
And the analysis stage of the screensaver is very slow.

I did not say all computers. I said SOME computers.

It cannot explain either why on another machine (with an ATI graphic chipset)
the screensaver is very slow (and eventually crashes) without the status bar
while it runs at normal speed with the status bar on.

I did not say it explained the status bar problem. And I have investigated the status bar problem and have come to the conclusion that it cannot possibly be caused by anything inside MyDefrag.

At last the fact that a screen saver runs at the idle priority level should not
make much difference since it's supposed to run while the system itself is idle.

Screensavers are not started when the system is idle. Screensavers are started if there has been no keyboard or mouse activity for some time.

I noticed that despite the fix in 4.2.4 the status bar of the screensaver still
does not display the percent analyzed (nothing after "processing disk C:").

Perhaps your screensaver was not updated? Which version does your screensaver show?

[scooper]

Hi there,

Having problems with the slow screensaver using MyD 4.3.1 I searched toe forum for a solution.
Then I found this thread here and could see my problem is already explained in detail.

I get no BSOD but the screensaver is very VERY slow.
The analysis phase in "normal" mode takes about 10 seconds.
With the "screensaver" mode I cancelled the operation after 3 minutes (!!).

I reverted to 4.1.2 as this version has been reported as functioning and using the "old" graphics engine and viola, now at screensaver mode it takes the 10 seconds it used to take.

I'm a software engineer and from MPOV there sems to be something wrong with the new gfx routines. Watching the disc map being draws I had the impression it takes ages for the renderer to figure out which bar to draw where for the file. The bar itself is drawn at an instant but there are long delays between the drawing of the individual files/bars.

Currently I am grounded to 4.1.2 as it is the only working version for me and I was crestfallen to see this problem is still around after one and a half years :<

[scooper]

Oh, one thing I observed:
When resizing the window in windowed mode the screen update is way more fluent in 4.3.1 than in 4.1.2.
Exactly the opposite is when using the screensaver mode: 4.3.1 is here waaaay slower than 4.1.2.

[BloodySword]

ATI graphic drivers are somewhat buggy. ATI / AMD graphic cards shoult therefore avoided.

I experienced another problem with ATI/AMD Catalyst:

With full Hardware Accelleration, the system of my girlfriend crashed with a blue screen, saying the same problem with grapic driver as the problem with MyDefrag in the beginning of this thread.

I downloaded the current Catalyst version for the HD card. It something called "Microsoft HD Audio Accelerator" or something, wich caused 70% CPU utilization while idle. When I deactivate this weird hardware (wich is actually not there, the card does not have an HDMI out) CPU went to normal.

Now YouTube works well. Strange uh? ATI/AMD is crap and should not be bought anymore!

[scooper]

YMMV I had never any problems with ATI/AMD to date an I am using their products now for many many years and believe me I use many different kinds of software, virtualization, operating systems andsoon... and they always perfectly worked. Please don't begin a fanboy flamewar.
Also don't install drivers for hardware you don't have or software you don't need (use "custom" at the installation process - always).
Deactivating hardware you don't need is useful, too, as OS ressources are freed (mem, cpu, irq, startup time, ...) and power consumption might possibly go down.

Back on topic:
Maybe the different graphic engine JK embedded triggers something at the display driver. However I have a good reason to doubt it because PoP wrote:

As  of Ver 4.2.x I have experienced a similar problem with the screensaver,
i.e. a slow (5 mns) to extremely slow (more than 1/2 hour) analysis stage,
depending on the machine desktop, laptop, netbook,
XP home SP1, xp  home sp3, xp pro sp3
all different video cards, NVidia, ATI Radeon mobile, Intel mobile.

You see - nVidia and Intel graphics experience the same effect, so it has nothing to do with the gfx-card's manufacturer, discrete or onbard gpu or operating system.

[BloodySword]

Also don't install drivers for hardware you don't have or software you don't need (use "custom" at the installation process - always).
Deactivating hardware you don't need is useful, too, as OS ressources are freed (mem, cpu, irq, startup time, ...) and power consumption might possibly go down.

I unchecked to install drivers for HDMI out, because this card does not have HDMI. The installer simply ignored it. The strange Microsoft HD Audio device was installed. I don't know how it is recognized. When I REMOVE this device out of the hardware manager, then research for hardware it is installed again. So I decided to deactivate this device to reduce the interrupt problems wich caused the CPU to be utilized 70% when idle.

The Catalyst drivers always were crappy. I had thausands reports of problems caused by ATI/AMD hardware. That's just my experience. I could fix them all, but a product wich costs money must not cause such problems!

Back on topic:

JK has mentioned several times that he did not change the graphics API, it are the SAME calls as in before versions.

I never used the screensaver but I will test it since I got home from work. My notebook has Intel GMA 4500 mobile graphics onboard and the display runs on 1680x945 pixels with Windows 7 pro 64 bit. I also have an old system with GeForce Ti 4200 and Windows XP SP3 32bit. I will test it there, too.

I will post the results as soon as possible.

The problem can be caused by another problem: In older MyDefrag versions, the display was updated in realtime. In actual versions, the display is updated approx. every 500 ms. All changes in this interval must be recorded and the graphics api calls are executed one after another. While using the windows GDI API it is important to free memory by destroying DCs (display contexts or device contexts) that are no longer used. Well then, when so many api calls are queued and executed very fast one after antother, it could be that the GDI garbage collector gets confused.

[scooper]

JK has mentioned several times that he did not change the graphics API, it are the SAME calls as in before versions.

I never used the screensaver but I will test it since I got home from work. My notebook has Intel GMA 4500 mobile graphics onboard and the display runs on 1680x945 pixels with Windows 7 pro 64 bit. I also have an old system with GeForce Ti 4200 and Windows XP SP3 32bit. I will test it there, too.

I will post the results as soon as possible.

Great! Both are non-AMD platforms.

The problem can be caused by another problem: In older MyDefrag versions, the display was updated in realtime. In actual versions, the display is updated approx. every 500 ms. All changes in this interval must be recorded and the graphics api calls are executed one after another. While using the windows GDI API it is important to free memory by destroying DCs (display contexts or device contexts) that are no longer used. Well then, when so many api calls are queued and executed very fast one after antother, it could be that the GDI garbage collector gets confused.

Interesting approach to cache and burst write requests. If I understood corrctly, the workload remains the same but it's individual drawing tasks not executed as they appear but are held for some time and then sent in quick succession to the GDI. Hm; what would be the benefit of this?

Possible would be to allocate a display buffer as char* and draw the lines by program code and have GDI only display the buffer. Wouldn't this be faster and more independent?

[BloodySword]

JK has mentioned several times that he did not change the graphics API, it are the SAME calls as in before versions.

I never used the screensaver but I will test it since I got home from work. My notebook has Intel GMA 4500 mobile graphics onboard and the display runs on 1680x945 pixels with Windows 7 pro 64 bit. I also have an old system with GeForce Ti 4200 and Windows XP SP3 32bit. I will test it there, too.

I will post the results as soon as possible.

Great! Both are non-AMD platforms.

Yes, the older system is an Intel Pentium III (1,1 GHz, 100 MHz FSB), the system is not stable anymore and is only used when my Laptop is in my own mintainance or for testings like this. RAM is 1 GB SDR 100 MHz.

Additional I want to run the screensaver without Aero as well as with Aero active on the notbook with Windows 7.

The problem can be caused by another problem: In older MyDefrag versions, the display was updated in realtime. In actual versions, the display is updated approx. every 500 ms. All changes in this interval must be recorded and the graphics api calls are executed one after another. While using the windows GDI API it is important to free memory by destroying DCs (display contexts or device contexts) that are no longer used. Well then, when so many api calls are queued and executed very fast one after antother, it could be that the GDI garbage collector gets confused.

Interesting approach to cache and burst write requests. If I understood corrctly, the workload remains the same but it's individual drawing tasks not executed as they appear but are held for some time and then sent in quick succession to the GDI. Hm; what would be the benefit of this?

The first point is, that such an approach will save CPU time, but not very much. The big point to this is what I guess JK uses:

He collects map changes and draws them in a small bitmap with the width of the whole visible screen in memory, when  500 ms are gone, the bitmap is drawed with BitBlt on the screen. Drawing directly on the screen is (for GDI) much slower than drawing in memory, then BitBlt on the screen. This saves A LOT OF CPU time!

Since every system should have a graphic card wich supports hardware accelleration this is the ideal time to use DirectDraw, especially for the screen saver. And direct draw has another benefit: The diskmap could be zoomed to create blocks like in most other defragmenters by setting the "point resize" flag, wich copies the nearest nighbour pixel, then he can apply a simple grid with 1px border. Then Jeroen does not need any buffer to draw into it, DirectDraw serves a buffer DIRECTLY in the graphic RAM!

Possible would be to allocate a display buffer as char* and draw the lines by program code and have GDI only display the buffer. Wouldn't this be faster and more independent?

I think this is what actually JK does in MyDefrag as described above and since he mentioned that he uses BitBlt, I think this is true.

Jeroen: Please correct me if I'm wrong.

[jeroen]

I think this is what actually JK does in MyDefrag as described above and since he mentioned that he uses BitBlt,

Yes, MyDefrag uses a memory buffer, and BitBlt to copy to the screen. There are no other graphic commands, no direct display access or whatever, I only use the standard BitBlt Windows call. In this respect both 4.1.2 and 4.3.1 are the same.

[BloodySword]

What about changing to DirectDraw?