oddities when rebuilding pngs #101
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
So, for the most part, this is a rather simple race. See commit messages (coming shortly). |
ulidtko
added a commit
that referenced
this pull request
Aug 29, 2019
Almost completely fixes #101 and #102. The issue is rather simple: * we run an example in a virtual X display, * we send events to the example via xdotool, * immediately after, we take a screenshot (with ImageMagick). We don't ever (and can't!) synchronize to a point "all X11 events have been pumped, handled, and the example has redrawn" -- so there's an obvious race happening. A little 50ms sleep should bias the race hard enough so that we always win it.
ulidtko
added a commit
that referenced
this pull request
Jul 12, 2022
Fixes #101 and #102. The issue is rather simple: * we run an example in a virtual X display, * we send events to an example via xdotool, * immediately after, we take a screenshot (with ImageMagick). We don't ever synchronize to a point "all X11 events have been pumped, handled, and the example has redrawn" -- so there's an obvious race happening. Fix the race by locating the PID of the example interpreter process, (it'll be the only child of our urxvt instance), and polling its process status (running or not). When we detect it's not running N times in a row -- conclude it's done and went idling. With increasing N, the total probability of misdetection drops exponentially. N=10 should suffice as a rough 1st guess; if the race reappears -- simply increase it a couple of points, say to 15 or 16.
ulidtko
added a commit
that referenced
this pull request
Jul 12, 2022
Fixes #101 and #102. The issue is rather simple: * we run an example in a virtual X display, * we send events to an example via xdotool, * immediately after, we take a screenshot (with ImageMagick). We don't ever synchronize to a point "all X11 events have been pumped, handled, and the example has redrawn" -- so there's an obvious race happening. Fix the race by locating the PID of the example interpreter process, (it'll be the only child of our urxvt instance), and polling its process status (running or not). When we detect it's not running N times in a row -- conclude it's done and went idling. With increasing N, the total probability of misdetection drops exponentially. N=10 should suffice as a rough 1st guess; if the race reappears -- simply increase it a couple of points, say to 15 or 16.
penguinolog
pushed a commit
that referenced
this pull request
Sep 28, 2023
Fixes #101 and #102. The issue is rather simple: * we run an example in a virtual X display, * we send events to an example via xdotool, * immediately after, we take a screenshot (with ImageMagick). We don't ever synchronize to a point "all X11 events have been pumped, handled, and the example has redrawn" -- so there's an obvious race happening. Fix the race by locating the PID of the example interpreter process, (it'll be the only child of our urxvt instance), and polling its process status (running or not). When we detect it's not running N times in a row -- conclude it's done and went idling. With increasing N, the total probability of misdetection drops exponentially. N=10 should suffice as a rough 1st guess; if the race reappears -- simply increase it a couple of points, say to 15 or 16.
penguinolog
pushed a commit
that referenced
this pull request
Sep 29, 2023
Fixes #101 and #102. The issue is rather simple: * we run an example in a virtual X display, * we send events to an example via xdotool, * immediately after, we take a screenshot (with ImageMagick). We don't ever synchronize to a point "all X11 events have been pumped, handled, and the example has redrawn" -- so there's an obvious race happening. Fix the race by locating the PID of the example interpreter process, (it'll be the only child of our urxvt instance), and polling its process status (running or not). When we detect it's not running N times in a row -- conclude it's done and went idling. With increasing N, the total probability of misdetection drops exponentially. N=10 should suffice as a rough 1st guess; if the race reappears -- simply increase it a couple of points, say to 15 or 16.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This isn't actually a pull request, but the easiest way to show my results.
When rebuilding the doc pngs, I got the below results.
Some came out find, but quite a few are blank, and some are slightly wrong.
Do you have any clues what I'm doing wrong?
Or, is there some regression that happened between the last regeneration and now?
A neat integreation test suite of sorts would be to rebuild the pngs during CI and assert there's no pixel-diffs.