Use img_hash for rendering tests#292
Conversation
|
@CryZe The |
ac1e111 to
0366b2a
Compare
src/rendering/software/mod.rs
Outdated
| // supported by Rust just yet. | ||
| not(all( | ||
| target_arch = "x86", | ||
| not(target_feature = "sse"), |
There was a problem hiding this comment.
If the image hash is good enough, we shouldn't need this anymore either.
There was a problem hiding this comment.
Seems like some of the image comparisons are still slightly off. Could we retrieve the images from the targets that are failing and see what it actually looks like?
There was a problem hiding this comment.
You could try to run these tests locally. Just install the specific target and run the tests with the target.
rustup target add i586-pc-windows-msvc
cargo test --all-features --target i586-pc-windows-msvc
Even now with the image hash? You may need to run Actually if you locally get a different hash, then the hash may not be robust enough. |
|
The tests pass for me after running |
|
I think keeping it on 0 for now is okay. Because the image we are getting now is actually fairly questionable. We are seeing some weird diagonal aliased line now, which may be worth investigating and reporting to whatever caused this. So I feel like we shouldn't just completely brush off notable changes like these via a larger tolerance value. |
|
Well, looks like we need a tolerance value on non-SSE platforms at least. Maybe we can use the cfg we had previously to conditionally give those platforms a larger tolerance value. |
|
Another way to minimize these problems should be to render the more broken tests in a higher resolution. That way minimal changes such as one glyph being +/- 1 pixel off causes less of a relative error. |
581cdb4 to
0465c1e
Compare
|
I switched to using
|
62f0b05 to
16a311d
Compare
|
I tried using bigger hashes, but that caused the rendering tests on the Linux mips builds to start failing for some reason. I haven't tried higher resolution rendering of the actual images yet. |
src/rendering/software/tests.rs
Outdated
| let expected_path = format!("target/renders/{}_expected.png", name); | ||
|
|
||
| if distance > get_comparison_tolerance() { | ||
| let actual_path = format!("target/renders/{}_actual.png", name); |
There was a problem hiding this comment.
I'm not sure if I'm too much of a fan of this. The old one had the advantage that I could switch branches and it still would find the expected image for the specific branch, so if visual changes would happen, it was still able to create a proper diff image.
There was a problem hiding this comment.
What we could do is throw the hash base64 string into AES to get highly scrambled bytes out again and revert the AES to get back the image hash for the expected AES hash.
There was a problem hiding this comment.
For now, I reverted to the old behavior of using the hash in the filename, but with the / all replaced with $ so that there's no issue with certain filenames. We can use AES if we think that the hashes being too similar is a problem (but I'm also not sure how to use the aes crate).
16a311d to
0c4e790
Compare
CryZe
left a comment
There was a problem hiding this comment.
I guess this is good enough for now. Good work! :)
Fix #287