glfw: window hint default values parity test with attributes #81
No reviewers
Labels
No labels
CI
all
basisu
blog
bug
build
contributor-friendly
core
correctness
deferred
dev
direct3d-headers
docs
driver-os-issue
duplicate
dxcompiler
editor
examples
experiment
feature-idea
feedback
flac
freetype
gamemode
gkurve
glfw
gpu
gpu-dawn
harfbuzz
help welcome
in-progress
infrastructure
invalid
libmach
linux-audio-headers
long-term
mach
mach.gfx
mach.math
mach.physics
mach.testing
model3d
needs-triage
object
opengl-headers
opus
os/linux
os/macos
os/wasm
os/windows
package-manager
priority
proposal
proposal-accepted
question
roadmap
slipped
stability
sysaudio
sysgpu
sysjs
validating-fix
vulkan-zig-generated
wayland-headers
website
wontfix
wrench
www
x11-headers
xcode-frameworks
zig-update
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
hexops/mach!81
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tests pass on my machine right now, but also unsure whether this is as comprehensive as it could be, hence the mess of comments. Any feedback or insights would be greatly appreciated.
Can you clarify which OS your machine is?
thought: maybe using a global var
testing_set_no_hintsandcomptime ifinsideWindow.createto disable the hinting calls would be simpler than all of this logic?All else equal, I'd prefer to keep tests a bit isolated (and consistent with eachother) so maybe ditch the
failedToCreateWindow(err)in this caseWhat do you mean by this? "as we've chosen a different default value"?
not worried about these
in recent GLFW versions, doublebuffer can also only be queried not set (which is super reasonable)
I'd say it's fine if we do not test all of these.
I left some thoughts inline, generally this looks great to me and it's OK if we don't have perfect coverage of every possible hint IMO. Just having something in place here for general sanity works for me.
@slimsag Sorry, it's been a rough couple of days for me. I'll try and get to your comments. And also, my primary OS is currently Windows 10, so tests passed there. Should have clarified that.
That's fair. I made it because I was running into some weird issues with block return and 'catching' errors from it, but I eventually figured it out, just didn't think to remove it.
Are you implying we use a global
comptime var? Because I don't think that's possible. Or do you mean something likeconst testing_set_no_hints = std.meta.globalOption("glfw_testing_set_no_hints") orelse false? I don't know if that would work, since I don't think (?) tests are treated as "root", though I'll have to check that.In the discussion here in my window hints rework pr, me and @silversquirl came to the accord that, seeing as GLFW doesn't specify a default value for
context_no_errorin their docs in this list, it would be most sane to default it to false (seeing as, in zig, we almost always want to handle errors with error codes, and avoid UB).Though, thinking about it now, and looking at the source code, it actually is defaulted to false (albeit not directly, it's done through a call to
memset), so there's no actual difference in behavior here. Though, maybe this calls for a pr upstream to add its default value to the aforementioned list in their docs? Then I could amend this "patch" in this pr.A different solution occurred to me. Make a normal global variable, but with this declaration:
Which would change the code inside
createto:I've committed the changes. I'll leave this as unresolved in case you have anything you want to clarify or suggest.
Ahh okay, I see. I was aware of the fact that it was implicitly set to false in GLFW through
memset(I double checked the defaults when I reviewed, which was why I was surprised to see this TODO)In that case, I am happy with this as-is and think we can just remove the TODO mention here.
@InKryption thanks a ton! And sorry to hear that :) FWIW your PRs have made my day for the past week or so, I really appreciate what you're doing, If I can buy you a coffee or two, let me know.
@ -3221,3 +3224,103 @@ test "setScrollCallback" {}}).callback);}@ -3221,3 +3224,103 @@ test "setScrollCallback" {}}).callback);}Pretty much LGTM!
Smart approach - I wouldn't have thought of that. Nice work.
@slimsag Appreciate the thought; and no worries, I really like what you have here, and thought I ought to try and help make it better, both for my own purposes, and as an added bonus, for others. As well, seemed like a friendly enough place to try making some more significant contributions for the first time.