Repository navigation
Port four native head fixes from DiffEngine - #48
Merged
Merged
Conversation
build-native built libbuildmonitor_ui.so on the runner's own Ubuntu 24.04. A library records the glibc symbol versions of the headers it was compiled against, and the committed ones need GLIBC_2.38, for __isoc23_sscanf, fmod and fmodf, and GLIBCXX_3.4.29. The loader refuses that on Ubuntu 22.04, Debian 12 and RHEL 8 and 9, so the Linux head could not open a window there and BuildMonitor exited. It is now built in a manylinux_2_28 container by native/build-linux.sh, the way DiffEngine builds its viewer's, and the workflow checks the result rather than trusting it: nothing above GLIBC_2.28, and nothing recorded as needed outside a short list. That container's linker records every library it is handed, and raylib hands on libSM and libICE, which a stock Ubuntu lacks, so the library is linked with --as-needed. Built that way from this commit, the linux-x64 library needs nothing above GLIBC_2.27 and GLIBCXX_3.4.21, and loads on the container's own glibc 2.28, where the committed one is refused. The committed binaries are not changed here: build-native rebuilds them and opens the PR.
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
raylib 6.0's CMake reads every SUPPORT_ flag in config.h into an option that defaults to ON, including the ones config.h sets to 0 (raysan5/raylib#5844), and CUSTOMIZE_BUILD skips config.h's own values. So SUPPORT_CUSTOM_FRAME_CONTROL was on, and EndDrawing neither swapped the frame onto the screen, polled input nor waited for the next one, all of which bm_present leaves to it for a frame it draws. SUPPORT_BUSY_WAIT_LOOP was on the same way, and WaitTime, which is how bm_present waits out a frame it does not draw, spun for the whole of it. Run under Xvfb with a window manager, the committed linux-x64 library leaves the window black, takes no keys, and from the first input draws without a pause, which under the software rasteriser is every core. With the window hidden it uses 15% of a core. Built from this commit the window is drawn, clicks and keys are acted on, an idle window costs 5% of a core and a hidden one under 1%. Switch both off, with every other flag config.h defaults to 0, the partial busy wait, and SUPPORT_SCREEN_CAPTURE, whose F12 writes a screenshot into the working directory when it is pressed while frames are being drawn. Of the picture formats only PNG stays on: the four others config.h enables are decoders nothing here calls. PixelTests.PresentWaitsForTheNextFrame times sixty drawn presents in the shown window. The pixel snapshots could never have noticed: a capture draws into a texture and never reaches EndDrawing. It takes 70 ms against the committed library and a second against this one. The committed binaries are not changed here: build-native rebuilds them and opens the PR.
raylib's PollInputEvents waits for an event, rather than polling, for as long as the window is minimised, unless FLAG_WINDOW_ALWAYS_RUN is set, and every bm_present makes that call. So the managed loop stopped with the window in the taskbar: the tray's icon and menu were no longer updated, no notification was shown, a click on the tray was not read, and a window command from the socket waited in its queue. With the raylib flags fixed and this flag left off, a show sent to a minimised window, which is what starting BuildMonitor a second time sends, did nothing until an X event reached the window. With it on, the window comes back.
NSApplication.run drains a pool per event, but this head never calls it: the managed loop calls in instead. With no pool pushed, objc4 parks everything autoreleased in one it creates for the thread, which drains only when the thread exits, and that is the main thread. So everything a frame autoreleased stayed until the process exited, in a tray that runs for days. Every entry point that touches AppKit now runs inside its own pool, as DiffEngine's do, bm_pick_directory and the tray calls among them. Not built or run: the Swift head cannot be built on Windows. The file parses and type checks under Swift 5.10 against stubs of AppKit and of the rest of the module.
NativeResolver tried the framework's own RID and then linux-{arch}, which is
the glibc build, so on Alpine the probe that was meant to miss found a
library after all. A musl RID now yields itself alone, as DiffEngine's
resolver does.
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
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
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.
Ports four fixes DiffEngine has made to the native head pattern BuildMonitor shares with it. One commit each.
Make the Linux head draw frames, read input and wait between them
raylib 6.0's CMake defaults every
SUPPORT_flag to ON underCUSTOMIZE_BUILD, including the onesconfig.hsets to 0 (raysan5/raylib#5844). SoSUPPORT_CUSTOM_FRAME_CONTROLwas on andEndDrawingneither swapped, polled input nor waited, andSUPPORT_BUSY_WAIT_LOOPmadeWaitTimespin.Run under Xvfb with a window manager, in Docker:
Those flags are now off, with the partial busy wait and
SUPPORT_SCREEN_CAPTURE(F12 wrote a screenshot into the working directory when pressed while frames were being drawn). PNG is the only picture format left on: that goes further than DiffEngine's list, switching off JPG and also BMP, GIF, QOI and DDS, whichconfig.henables by default.PixelTests.PresentWaitsForTheNextFrameis new and Linux only. It takes about 70 ms against the committed library and fails, and a second against this one. It will fail for anyone running the pixel tests against the committed binaries until they are rebuilt.Keep the Linux loop running while the window is minimised
PollInputEventswaits for an event while the window is minimised unlessFLAG_WINDOW_ALWAYS_RUNis set, and everybm_presentcalls it. With the flags above fixed and this one off, a show sent over the socket to a minimised window did nothing until an X event reached it. With it on, the window comes back.Run every macOS entry point in an autorelease pool
The head never calls
NSApplication.run, so nothing drained the main thread's pool. Not built or run locally: the file type checks under Swift 5.10 against stubs, and this branch's Build native run is its first real compile.Probe a musl RID and nothing else for the native library
NativeResolver.Rids(string)yields only the exact RID when it contains-musl-. Tests inNativeResolverTests.Not in here
HeadLocator.Rids()in the launcher has the same musl fallback.