Disable fade-in on start

[dominicraf]

vDos has a pretty 'fade-in' feature when it starts, but this takes a bit of time, particularly when the machine is being accessed remotely. Can it be disabled?

[Jos]

That bit of time is 0,465 seconds: 32 steps with a 15 ms delay in between.

It cannot be disabled. You get a noticeable longer time with a slow remote connection?

Jos

[dominicraf]

I agree that running locally the time is acceptable for the prettiness. But using RDP even with remote connection of 17Mbit/s it is quite a bit slower. Probably because each of the 32 steps has to be scanned and sent to the remote machine. As we start and stop the application frequently the time wasted is significant. And we run in 43 line mode (not 25) which probably does not help.

[Jos]

It is not scanning, but copying the window content. The number of lines doesn’t reflect the amount of data to send, only the window size.

I did a test with a 1366x768 window and a throttled bandwidth of 17Mbps. But noticed no added delay
Perhaps others can comment with a use case of RDP.

Jos

[dominicraf]

Thanks Jos, I have now been able to run some tests. Startup seems to increase from c.3.3 seconds (locally) to c.3.7 seconds (over RDP, 17Mbps, vDos window c.800x900, overall screen 1920x1080), and seems to reduce to c.3.5 seconds if the overall screen size is 1366x768. 0.4 seconds extra is not a big deal I agree, though I would still prefer to be able to disable the fade-in.

[Jos]

You measured 3.3 to 3.7 seconds for the time the vDos window takes to go from 100% transparent to opaque? It’s not mainly the time for the program to start?

As said, transparency drops in 32 steps to 0% with a 15 ms delay in between. That gives a total delay of 0.465 seconds.
I verified that by logging each step.

Even with the original low resolution system clock of 18.2 ticks per second the maximum delay would be 31*0.055 = 1.7 seconds.
But modern PC’s (and Windows) have a more precise clock.

I changed the number of steps to 16 and a 30 ms delay. Of course resulting in nearly the same total delay, 0.45 seconds (0.82 with a 18.2 ticks clock).
But that will halve the number of window image transmissions with RDP.
DOS content is normally fairly uniform with few colors and so has a high compression ratio.
If the initial background of the vDos window is however more complex, like with many desktop icons, (de)compression takes more time and a larger data stream to transmit.

Jos

[dominicraf]

Thanks Jos that change should help a bit. Yes the time I am measuring includes everything from the initial click on the icon to my program's initial screen fully displaying (i.e. fading in). The VDos screen is pure text (albeit 43 x 80 not 25 x 80) using THEME = 1.

[Jos]

I don’t think the change will do a lot, probably only a fractional faster fade-in with a slow RDP connection.

You could add a PAUSE command to autoexec.txt, right before your program is started. To verify the (extra) delay is indeed caused by that.

If the vDos window appears promptly and the program then also starts without a real delay, vDos doesn’t detect the program is ready to accept user input.
Essentially the vDos window is then shown, with a timeout of 2 seconds if no keyboard interaction is detected.

I however noticed some weeks ago one method of interaction is missed. So that could account for an additional delay of up to 2 seconds.

Jos

[dominicraf]

I had not realised that (without the pause) it is possible to type into our program while it is fading in, no need to wait for the fade-in to complete before starting typing.

Using pause as you suggested: the start up (up to the 'Press any key to continue . . .') is c.1.3 second (including fade-in), then there is a delay of c.2 seconds after I hit a key for my program to load and display (no fade-in at this stage). (In both cases running remotely.)

FYI re the detection: our program is compiled Basic (VBDOS) and, after initialising and loading the first screen, uses INKEY$ in a loop to await user input. If an unnecessary 2 second delay could be avoided, that would be great.

[Jos]

The potential extra delay of up to 2 seconds doesn’t apply, your program takes 2 seconds to start.
Rather lengthy, you could eventually start vDos with the logging option (….\vDos.exe /log).
And look in the generated vDos.log file for some clue why it takes that long.

Jos

[dominicraf]

OK thanks will investigate that in due course.