DosTips.com

EDIT:

Aacini wrote:Let me clear a couple points:

1. Of course, there are a lot of other details we could test, like use native screen resolutions, or use different CPU cores (via Task-Manager or "start" /AFFINITY), and a long et cetera... However, all these "Different methods to decrease the screen flicker" are NOT the matter of this thread!
2. This topic was created by einstein1969 in order to publish an antiflicker method devised by him, that is based on the following points:
   
   • Fact: Windows 7 featured a new method "to group multiple software timer expirations into a single period of processing", that MS called "timer coalescing".
   • Hypothesis: The timer used to update the %time% cmd.exe dynamic variable have a resolution of about 15.6 ms because it uses Windows 7 timer coalescing feature. The method used by cmd.exe to show characters in the window screen also use timer coalescing. In this way, if the display of characters in the screen is delayed until the %time% variable change, the screen flicker should decrease. This is called the "timer coalescing" antiflicker method.

I replied with my point that the Windows 7 "timer coalescing" feature have no relation with %time% variable nor with the display of characters on the screen, but that any decrease in the screen refresh rate (like a wait for a change on %time% variable) will decrease the flicker.

Although a test proved that this method don't works on my computer (nor in aGerman's one), einstein1969 insisted on his theory and diverged the cause of the flicker to other factors ("Peraph on monocore machine the timer colescing work well ?"; as corollary: the timer coalescing dont work on multicore machines). After this reply, @penpen posted this:

penpen wrote:On my win10 it depends on the core which is used to execute it:
On one core there is flickering (and a frame rate of ~68fps), on the other i have ~96 fps and only rare flicker.

penpen

How could I know that this reply is not about the "timer coalescing" antiflicker method, but about an entirely different matter?

IMHO the replies that are unrelated to the topic should include some kind of advice, in order to avoid confusions...

Antonio

I have used in my project a anti-flicker method that work on " Windows seven".

But i have discovered that there is a case that this not work well.

The method used in the game SNAKE of Dave Benham is to draw FAST and little.

This method work on xp and over.

The fastest method for draw is using the ECHO with multiple line Buffer.

I have seen that other user use a one ECHO with LF separator and seem faster.

Than I have discovered a method for antiflickering on window Seven that use a timers coalescing.

Recently i have discovered that this not work well in cases of APPLICATION active. Esample: Browser, Windows Audio/Video Players, some kinds of configurations.

I use a configuration with not DESKTOP COMPOSITION (AERO)!

When this is active the antiflicker don't work. It's possible disable in compatible option of executable but i have not tried.

Can someone try this?

einstein1969

Hi,

This is a batch code that use this features.

You can probe with closing all application and disabling COMPOSITING DESKTOP. (in system -> advanced option -> performance and unflag the relative option)



Can someone test on other system operating? and confirm on windows seven?

einstein1969

einstein1969 wrote:The fastest method for draw is using the ECHO with multiple line Buffer.

I have seen that other user use a one ECHO with LF separator and seem faster.

Of course. I don't know why I hadn't thought of that. Thanks for posting.

I've updated my SNAKE.BAT to use one screen variable with LF and it significantly reduces the amount of screen flicker when CurserPos.exe is absent.


Dave Benham

I never read about the syntax: but works.

About LF I think unnecesary, because console screen buffer can be treated as single row.
For example this line for fill a hypotetic screen buffer size of 2x5:
XXXXX\nXXXXX
can be treated as:
XXXXXXXXXX

dbenham wrote:

einstein1969 wrote:The fastest method for draw is using the ECHO with multiple line Buffer.

I have seen that other user use a one ECHO with LF separator and seem faster.

Of course. I don't know why I hadn't thought of that. Thanks for posting.

I've updated my SNAKE.BAT to use one screen variable with LF and it significantly reduces the amount of screen flicker when CurserPos.exe is absent.


Dave Benham

have you tested the antiflicker with timer coalescing?

@carlos
if the screen is larger than lines printed, the velocity is major using LF terminator.

einstein1969

Hi,

This code show if the timers coalescing work.



Can anyone confirm if the flicker is reduced? On my machine this work

EDIT:code modified because go infinite loop!


Einstein1969

einstein1969 wrote:This code show if the timers coaleshing work.

Is this what you mean? coalescing

Can anyone confirm if the flicker is reduced? On my machine this work

It works well here in Win 8.1 - tiny video below.

http://astronomy.comoj.com/dostips/flicker-test.wmv

Sorry foxidrive, my english is not good. I mean coalescing.
Thanks for the video! It seem that work in windows 8.1 too

Wich software are you used for produce?

einstein1969 wrote:Thanks for the video! It seem that work in windows 8.1 too

Which software are you used for produce?

FastStone Capture. It has a lot of capability of the very expensive SnagIt but is much cheaper.

This code is more simple than previous and achieve same result
This work on windows 7,8.x (10 not tested)



This use variuos tricks for work. The code use parentesis () block for fast execute and percent % expand phase.
It wait until change the TIME than clear and draw fast the screen.
The first not empty line can blink on certain machine. In this case I use to write the first line empty with nbsp (Non-breaking space or no-break space).
You must use EnableDelayedExpansion

Einstein1969

Thanks a lot!

The last script was very SLOW due GOTO :LABEL
I have rewritten for very FAST way to draw near TIME change. I use 3 FOR loops for fast skip.

This is new code:


This work on very FAST machine too I hope.

einstein1969

I reviewed this topic again because your recent reference about it. I would like to make some comments...

The flickering effect appears when an animation is based on clear the entire screen and then refresh the entire screen. This problem mainly depends on the size of the screen and the speed of the refresh: if the screen becomes smaller or the refresh becomes faster, the flickering effect decreases.

Of course, this effect also depends on the times per second that the screen is refreshed (refresh rate). However, this number depends on the requirements of the animation itself. If this number is diminished, the animation don't look smooth anymore, but jagged and with leaps.

My first (somewhat pedantic) comment is that "Anti-Flicker" is a term that suggest that the flicker effect is cancelled, so it is not appropriate here. If a method diminish the flickering effect in 25%, it is "25% Anti-Flicker" or "75% Anti-Flicker"?

However, the most important point in this topic is that you never explained the method. In the first post, you said:

einstein1969 wrote:I have used in my project a anti-flicker method that work on " Windows seven".

But i have discovered that there is a case that this not work well.

. . .

Than I have discovered a method for antiflickering on window Seven that use a timers coalescing.

Recently i have discovered that this not work well in cases of APPLICATION active. Esample: Browser, Windows Audio/Video Players, some kinds of configurations.

I use a configuration with not DESKTOP COMPOSITION (AERO)!

When this is active the antiflicker don't work.

. . .

And in the next post you said: "This is a batch code that use this features". Which features are you talking about? How this method work? What I need to modify in my application in order to use your method? Why do you call it "timers coalescing"? How the method is related to "COMPOSITING DESKTOP" status? I HAVE NO IDEA!

After I reviewed your code I concluded that your method consists in decrease the refresh rate. Of course, this method decrease the flickering, but it can only be used when the animation allows to do so (and I am still wondering how "timers coalescing" is related to "decrease refresh rate").

Antonio

Hi Antonio,

This discovery uses a discover on how the dos time change. ref.1



I discover that the time on my machine is near 15ms and searching in the web I found that the default timer change at 64 Hz.
ref.2 and ref.3

In this document there is a reference that confirm the previous and introduce the timer coalescing concept.
Timer resolution

When I read this:

Windows 7 introduced timer coalescing, which allows scheduled timers to specify a tolerable delay for timer expiration. For example, a scheduled timer that has a period of 200 ms may specify a tolerance of 20 ms. This allows Windows to group multiple software timer expirations into a single period of processing.

I presume that the DOS time change when a timer coalescing occur
I presume that the other graphics function occur when the timers coalescing. Ie the writing on the screen at screen REFRESH rate

Than I have done some experiment that confirm this tesis.

When the DOS timer change the graphics device write on screen. Than we have time to rewrite the screen until next write.

Can this explain why this is an reduced flicker method?

If you reduce only the frequency of redraw and not sinc to DOS timer change the flicker is not reduced to much.

Einstein1969

Ok. This description makes clear what you called the "timer coalescing" Anti-Flicker method, but I think this is the first time you explain all these concepts in this way. These are the points I understood from your description and some additional comments.

There are two important points in the quoted phrase, that I marked here in bold face:

Windows 7 introduced timer coalescing, which allows scheduled timers to specify a tolerable delay for timer expiration. For example, a scheduled timer that has a period of 200 ms may specify a tolerance of 20 ms. This allows Windows to group multiple software timer expirations into a single period of processing.

Although I didn't read the whole document, I am convinced that the "scheduled timers" that are "grouped into a single period of processing" (that is the meaning of the timer coalescing term) are used in "software timer expirations", that is, in timers SCHEDULED BY USERS PROGRAMS. The computer system use different time counters ("timers") in multiple situations, starting by take count of the real-time clock, but also when accessing a series of devices, like the repeat rate of the keyboard keys, etc. However, all these timers are HARDWARE TIMERS that don't support any kind "tolerable delay for timer expiration". Just guess what would happen in the system if anyone of these hardware timers, that requires an immediate response when the timer expires, would be delayed or hasten a few milliseconds each time!

I ignore the reasons because the %time% cmd.exe dynamic variable have a precision of 15 ms, but I am pretty sure that the reason have absolutely no relation with the "timer coalescing" feature introduced in Windows 7. Also, I am pretty sure that the output of new contents in the screen that the Win-32 API functions performs under request of cmd.exe is NOT LIMITED by any kind of "timer", but it is performed as soon as the output is requested and at the maximum possible speed that this output can be performed. Of course, there are internal hardware restrictions about the maximum speed of the screen refresh, but that point is an entirely different matter. In order to explain this point, I want to...

( ... open a big parenthesis.

First of all, I invite you to read this article that explain what is screen refresh rate. After that, I want to tell you a small story...

Many, many years ago, when the OS for the PC computers was MS-DOS 2.11 and the only available video cards were CGA and MDA (and the dinosaurs roaming the earth), I wrote a program in assembly language that performed several interesting things. First, it created an additional video line, the number 26, reprogramming the controller chip of the video card; then, it uses such an additional line to show a clock with chronograph and timer capabilities.

At that time, the standard way to show characters in the screen was using BIOS INT 10H video functions, but that method was slow. The contents of the screen was stored in a certain memory area in the video card, but that area was also Memory Mapped to (associated with) addresses that are directly accessible by the CPU, so a program may show text in the screen storing characters in this area. However, the modification of this memory area must be done following certain rules; otherwise, the screen flickers.

The right way to do such video memory mapped modification was poll the video controller chip for the status of the refresh beam and wait until the next vertical retrace cycle start, that happen once each 1/30 second (half the screen refresh rate: 60 Hz); then, modify the video memory for one character. In order to show another character, the program must wait for the next vertical retrace cycle. This method works perfectly and allows to show characters in the screen with no flicker. )


In conclusion, IMHO you had combined a series of non-related concepts that may lead to a wrong conclusion. Note that I am NOT saying that your method is wrong! If a relation between the %time% variable and the screen output, that may reduce the screen flicker, can be found, then such a relation would be useful. However, I think that prove this thesis may be difficult: how do you measure the amount of screen flicker on the screen? If you don't use an exact, non-subjective method, then the results will not be conclusive. As I said before, any decrease in the screen refresh rate will also decrease the flicker.

Even in the case that the effectiveness of this method could be confirmed, it may not be suitable for certain animations. For example, in Snake, Tetris and many other animated games the program must respond to a key press as soon as possible, particularly in advanced game stages when the pieces move faster. If after a key press the program must wait for the next DOS time sync in order to refresh the screen, then the game will lost its playing experience.

Just my opinion...

Antonio