Add mode Bm #146
Merged
Add mode Bm #146
Conversation
This file contains hidden or 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
+ add cobble together a working resize for the window_glfw helper class
+ add it for the receiver webapp as well.
We check on resize(), but the bounding rect doesn't seem to have been updated yet (perhaps due to the animation?). But it has by the time we close the menu...? In any case, this sanity check tied to a user action, so that's nice
…hack We have a styling width mismatch with the hack anyway, so we're stacking weird fixes atop weird hacks. Or we can do it this way and avoid all that. Also eliminates: * the pretty awful attempts to center the text box pseudoelement * the rotation transition animation (rip, animations are cool) * the nav button hiding weirdness (see previous commit)
Missed these in the big refactor
sz3
commented
Oct 10, 2025
| else if (mode == "Bm" or mode == "BM") | ||
| config_mode = 67; | ||
| } | ||
| cimbar::Config::update(config_mode); |
There was a problem hiding this comment.
This bit of code is duplicated a few places. Probably time to split it out (realistically: next time I add a new config)
sz3
commented
Oct 10, 2025
| if (rotate) // 90 degrees | ||
| { | ||
| _window->rotate(); | ||
| _window->rotate(); |
There was a problem hiding this comment.
The existing rotation implementation has a weird rotation order due to what I initially implemented it for (an alternative attempt at the "shakycam" jitter we use to fast-fail bad frames). So 90 degrees is 2 "rotations", even though that makes no sense. (will probably change it to act normal in a followup)
sz3
commented
Oct 10, 2025
| _height = height; | ||
| glfwSetWindowAspectRatio(_w, width, height); | ||
| glfwSetWindowSize(_w, width, height); | ||
| init_opengl(width, height); |
There was a problem hiding this comment.
resize() has to be a bit smarter now...
sz3
added a commit
to sz3/cfc
that referenced
this pull request
Oct 11, 2025
Mergin sz3/libcimbar#146, a.k.a libcimbar:7561ff0a3fa8a45d7a753ca9db1137817201f636. Will be equivalent to the 0.6.3 libcimbar release. Includes mode Bm and the new config system (sz3/libcimbar#143)
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
A long-running theme in the development of this "file transfer via the camera" idea is that there's a non-negotiable tradeoff between transfer speed and compatibility. In striving for fast transfers, we must sacrifice some low end devices, and for a 1024x1024 format that means any of device with a 720p camera.
At the same time, for a while I've thought it would be nice to have a smaller format for broader compatibility, even if performance suffers as a result. Some fine folks have even tried to do it themselves: #72
Finally, to put this idea over the edge from "nice to have": the introduction of the web decoder (re.cimbar.org) and the unpredictability of webcam performance means a more robust (even if slower) format will be helpful.
So: for 0.6.3, we'll add an experimental config
mode Bm(I think of it as "B mini", or maybe "B minor" if you're music-theory inclined) that should work on a broader variety of cameras. It's a 1024x720 image (vsmode Band4C's 1024x1024), so it has a fighting chance of working with 720p. It's also the first non-square configuration, which helps make up for some of the resolution loss in overall performance.Code changes:
Bmconfig went in with Config system update for proper runtime configuration #143. See also: non-square grid dimensions + miscellany #129, Update default cimbar.js encoder config to "mode B" + wide config futureproofing #130cimbare_rotate_window()in the C api. It's not relevant for square cimbar configs.