Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp in the log file is inaccurate #511

Closed
darkhandz opened this issue Feb 14, 2022 · 6 comments
Closed

Timestamp in the log file is inaccurate #511

darkhandz opened this issue Feb 14, 2022 · 6 comments
Labels
duplicate This issue or pull request already exists

Comments

@darkhandz
Copy link

darkhandz commented Feb 14, 2022

WindTerm 2.3.0 PreRelease 4
win10 19044.1469
Session: Serial

I found the relative time in logging function is not same as margin's.
Like the screenshot below, in fact, the higlighted lines are about to print out at the same time (margin time is right), but log file show that they were output at different time (line 3039 is about 20s later than line 3038, and 3040 is similar).

image

@kingToolbox
Copy link
Owner

Duplicate of #497

The timestamp in the log is the time when the log is written to disk, so there is a delay compared to the time when the text is received.

I will improve this in the next bugfix version WindTerm_2.3.1, which is expected to be released this week. Please stay tuned, thank you.

@kingToolbox kingToolbox added the duplicate This issue or pull request already exists label Feb 16, 2022
@kingToolbox
Copy link
Owner

I am happy to inform you that WindTerm_2.3.1 has been released and this issue has been fixed. Please download and check it. If there are still bugs, please let me know, thank you.

@darkhandz
Copy link
Author

Finally, the new verison comes out, thanks for your hard work.👏

I found something interesting in v2.3.1, like the pic below, the log file shows line 1577 and 1578 has different timestamp, but session windows shows they are same, I guess maybe log file is more accurate?
And in the blue rect, line 1595 1598 1600 shows an early timestamp, is this cause by the invisible character (%v) ?

image

@kingToolbox
Copy link
Owner

You are really very observant. 😄

As you analyzed, the timestamps in the logs are more precise. But why are the ones shown on the screen less accurate?

Before we talk about this, we need to understand how the server refreshes the screen. In fact, the server doesn't refresh line by line, but wherever there is a change. That's why those blue lines are older than the context, because they are empty lines that don't need to be updated again after the first created (%v is a bug).

Another feature is that the server sometimes does not just refresh the new and deleted text, but refreshes more text, or even the whole screen. As shown in the screen, all the lines were output once at 12:08:43:990, but somehow some of them were refreshed again at 12:08:44:007. All of this is well recorded in the log.

Since most of the text printed before and after was the same, WindTerm compared the text when drawing the screen and discarded the same parts to improve performance, in addition to avoiding visual changes for the user. So for the second
12:08:44:007 update above, it was discarded completely and the timestamps definitely remains unchanged. After all, people prefer static text content.

There are also some designs and techniques that will not be described in detail. I believe almost no other terminals can display the time of each line as well as WindTerm. But in order to develop this feature well, it took a lot of time to polish it.

@darkhandz
Copy link
Author

I hope this issue doesn't take up too much of your time🤣
Since the log file is precise enough, it satisfy my demand, margin timestamp is just for realtime reference.

@kingToolbox
Copy link
Owner

Not at all, as this issue should have been resolved and will be closed. 😄 You are welcome to continue to file new feature requests and bugs, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants