Hyperion Entertainment Message Boards

Heh, so this thread gets reactivated a second time, long time to grow...

TL;DR?
Just browse the bold lines then...

I think i found the culprit.

I was doing lots of compiling lately, stuff that took time and would eventually send my monitor into blank state (not sleep) and sometimes it did not wake from it. (no crash, just a silent freeze in the background with a blanked screen)

While doing the compiling and surfing the net with Odyssey i was pretty low on gfx mem (256 max with the gfx driver, having about 170 mb in use).
I also have a gfx mem docky installed which warns me (through Notification and sound) once i go beyond 75 %.

The Notification sound gimmick i just recently discovered and that was the one that alerted me actually to something going on in the instant the monitor was sent to blank itself.
Right then the Notification sound went off and i immediately moved the mouse to see what happened.
There was the Notification message telling me gfx mem was over 75% used...but, it wasn't (judging from the gfx mem docky display).
So i waited some more and it happened again on the next blank, but this time i caught the docky display to actually show it has been filled. And i also just caught that it went down a whooping 50 MB in gfx mem usage, so it went up the same amount beforehand.

I have to add that i don't use ANY modules, i just let the screenblanker engine blank the screen and wait for the sleep mode to come up later.

So...

Why is ScreenBlanker engine wasting a 50 MB gfx mem package to just blank the screen?
Would it be possible to reduce this kind of used gfx mem to a minimum IF no modules are set to be used?
Or, at least, let ScreenBlankerEngine check the available gfx mem first, instead of violently grabbing (non-existance) memory?

Since i know, because i already bombed my system numerous times with purposely filling up the gfx mem, that ScreenBlankerEngine is the one causing all those freezes people talked about in this very thread, it would be nice to get someone to open a tracker item (or at least update the one that might already be there) and share the tracker # with us mere users.

Thank you

I haven't tried, but a somewhat easy way to reproduce it would be to fill up the gfx memory to 85-90% and let ScreenBlankerEngine do it's stuff.

At least, i now know why it freezes (not that i can do anything about it)

I have no modules whatsoever in "Active modules"
ScreenBlankerEngine 53.13 (03.10.2014)

ScreenBlankerEngine doesn't allocate any large amounts of RAM (only a few structures here and there). I suspect that your "50 MB" is associated with opening a new screen to show a blanker animation. I haven't checked the code to see if it does this before checking for an animation to display.

What is your screen resolution?

tonyw wrote:ScreenBlankerEngine doesn't allocate any large amounts of RAM (only a few structures here and there). I suspect that your "50 MB" is associated with opening a new screen to show a blanker animation. I haven't checked the code to see if it does this before checking for an animation to display.

What is your screen resolution?

Yes, that might be the reason, my resolution is 1920x1440, so, large enough for that amount of ram.
Then again, why is it even doing it when my settings clearly state that there is no animation to be done, as there is no module available AND i told it to only "blank" the screen?

hypothesis
While i get that for "blanking" the monitor, a new (blacked) screen is simply opened and moved in front of the current screen, i don't understand the size of the used ram for it.
Also, if a new (blacked) screen in that reoslution will eat away 50+ MB why not simply open a (blacked) screen in the smallest available screenmode and show that instead?
/hypothesis

Of course, i don't know how ScreenBlankerEngine actually works, but it does sound like a waste of precious memory...

...it does sound like a waste of precious memory...

I agree, but at the time that the screen blanker code was written (~2010 ?), screens didn't occupy 84 MB very often.

During my recent forays into video device drivers, I have learned that there is an API entry to "switch off" the video output. Although that might not be supported by every available graphics card, it ought to be easier to blank a screen that way.

I'll write a BZ suggesting some improvements.

tonyw wrote:

...it does sound like a waste of precious memory...

I agree, but at the time that the screen blanker code was written (~2010 ?), screens didn't occupy 84 MB very often.

During my recent forays into video device drivers, I have learned that there is an API entry to "switch off" the video output. Although that might not be supported by every available graphics card, it ought to be easier to blank a screen that way.

I'll write a BZ suggesting some improvements.

I see, makes sense, time and electronics move on

I check with a gfm mm logger and it's exactly 43 MB that gets eaten.

Thank you for the BZ