chore: remove electron-build folder

2026-04-04 14:51:23 -07:00
parent f9f4beb4b2
commit 8dbaabe6fb
3 changed files with 0 additions and 230 deletions
@@ -1,193 +0,0 @@
 # Building Patched Electron 42 (Input Priority Fix)
 This builds a custom Electron with a one-line Chromium patch that fixes input starvation ("aim freeze") when `--disable-frame-rate-limit` is active. Without this patch, uncapped frame rates cause 50-300ms input delays in GPU-intensive applications like browser FPS games.
 ## The Problem
 Chromium's main thread scheduler gives input tasks `kHighestPriority`. At uncapped frame rates, the compositor floods the task queue and input events get starved — your mouse movements are delayed by up to 300ms, then snap to catch up. Chromium 87-93 had `ImplLatencyRecovery`/`MainLatencyRecovery` features that mitigated this, but they were removed in Chromium 94.
 ## The Fix
 One line in `main_thread_scheduler_impl.cc` — demote input tasks from `kHighestPriority` to `kNormalPriority`, allowing the scheduler's anti-starvation logic to fairly interleave input and compositor work.
 ## Prerequisites
 - **OS**: Windows 10/11 x64 (builds on Linux too, adjust paths accordingly)
 - **Disk**: ~100 GB free (Chromium source + build artifacts)
 - **RAM**: 16 GB minimum, 32 GB recommended
 - **Visual Studio 2022** with "Desktop development with C++" workload and Windows 11 SDK
 - **Git** and **Python 3.8+** on PATH
 ## Step 1: Install depot_tools
 ```powershell
 cd C:\
 git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
 # Add C:\depot_tools to the FRONT of your system PATH
 # Then open a NEW terminal
 ```
 Verify: `gclient --version` should print a version.
 ## Step 2: Check out Electron source
 ```powershell
 mkdir C:\electron && cd C:\electron
 # Create gclient config for Electron
 gclient config --name "src/electron" --unmanaged https://github.com/nicedayzhu/electron.git@v42.0.0-nightly.20260227
 ```
 > **Note**: Replace the repo URL with your fork if you've pushed the patch there. The `@v42.0.0-nightly.20260227` pins the exact nightly tag.
 ```powershell
 # Sync all dependencies (~40-60 GB download, takes a while)
 gclient sync --with_branch_heads --with_tags
 ```
 ## Step 3: Apply the patch
 ```powershell
 cd C:\electron\src
 # Apply the patch file
 git apply --directory=. path\to\input-priority-fix.patch
 ```
 Or make the edit manually — in `third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc`, find:
 ```cpp
 case MainThreadTaskQueue::QueueTraits::PrioritisationType::kInput:
    return TaskPriority::kHighestPriority;
 ```
 Change `kHighestPriority` to `kNormalPriority`.
 ## Step 4: Configure the build
 ### Release build (optimized, for distribution):
 ```powershell
 cd C:\electron\src
 # Create build directory
 gn gen out/Release
 # Copy the release args
 copy path\to\args.release.gn out\Release\args.gn
 # Regenerate build files with the new args
 gn gen out/Release
 ```
 Contents of `args.release.gn`:
 ```gn
 import("//electron/build/args/release.gn")
 is_official_build = true
 use_remoteexec = false
 use_reclient = false
 ```
 ### Testing build (faster compile, for development):
 ```powershell
 gn gen out/Testing
 ```
 Write to `out/Testing/args.gn`:
 ```gn
 import("//electron/build/args/testing.gn")
 use_remoteexec = false
 use_reclient = false
 ```
 Then: `gn gen out/Testing`
 ## Step 5: Build
 ```powershell
 cd C:\electron\src
 # Release build (~2-4 hours depending on CPU)
 ninja -C out/Release electron
 # OR Testing build (~1-2 hours, less optimization)
 ninja -C out/Testing electron
 ```
 > **Tip**: Use `ninja -C out/Release electron -j N` to limit parallelism if you're running out of RAM (where N = number of parallel jobs, try RAM_GB / 2).
 ## Step 6: Create distributable zip
 ```powershell
 cd C:\electron\src
 # Generate the electron dist zip
 python3 electron/script/zip_manifests/create-dist-zip.py out/Release
 # Or use electron's strip-binaries + create-dist tooling:
 ninja -C out/Release electron:dist_zip
 ```
 The output zip will be at `out/Release/dist.zip` (or similar). This contains `electron.exe` and all required DLLs/resources.
 ## Step 7: Verify
 Extract the zip and test with a minimal app:
 ```powershell
 # Create a test directory
 mkdir test-app
 ```
 Create `test-app/package.json`:
 ```json
 { "name": "test", "version": "1.0.0", "main": "main.js" }
 ```
 Create `test-app/main.js`:
 ```js
 const { app, BrowserWindow } = require('electron');
 app.commandLine.appendSwitch('disable-frame-rate-limit');
 app.commandLine.appendSwitch('disable-gpu-vsync');
 app.whenReady().then(() => {
    const win = new BrowserWindow({ width: 1280, height: 720 });
    win.loadURL('https://krunker.io');
    win.webContents.on('did-finish-load', () => {
        console.log('Electron:', process.versions.electron);
        console.log('Chrome:', process.versions.chrome);
    });
 });
 ```
 Run it:
 ```powershell
 path\to\electron.exe test-app
 ```
 If Krunker loads at uncapped FPS with no aim freeze, the build is good.
 ## Using the patched Electron in a project
 To use this as the Electron binary in an npm project:
 ```powershell
 # Set environment variable to point to your custom build
 set ELECTRON_OVERRIDE_DIST_PATH=C:\path\to\extracted\electron-dist
 # Then run your Electron app normally
 npm start
 ```
 Or replace the contents of `node_modules/electron/dist/` with the extracted zip contents.
 ## Build time estimates
 | Build type | CPU | Approx. time |
 |---|---|---|
 | Testing | 8-core | ~1-2 hours |
 | Testing | 16-core | ~30-60 min |
 | Release | 8-core | ~3-5 hours |
 | Release | 16-core | ~1.5-3 hours |
 Release builds are significantly slower due to LTO (Link-Time Optimization) which does a whole-program optimization pass.
@@ -1,8 +0,0 @@
 import("//electron/build/args/release.gn")
 # Full optimization (LTO, minimal symbols, etc.)
 is_official_build = true
 # Not using Google's remote build infrastructure
 use_remoteexec = false
 use_reclient = false
@@ -1,29 +0,0 @@
 From: Krunker Civilian Client <krunker@crjlab.net>
 Subject: [PATCH] Fix input starvation when frame rate limit is disabled
 Chromium's main thread scheduler assigns kHighestPriority to input tasks,
 which starves the compositor when --disable-frame-rate-limit is active.
 At uncapped frame rates (300+ FPS), the compositor floods the task queue
 and input events get delayed 50-300ms, causing "aim freeze" in games.
 Demoting input tasks to kNormalPriority allows the scheduler's built-in
 anti-starvation logic to fairly interleave input and compositor work.
 Benchmarked via CDP Input.dispatchMouseEvent:
 - p99 latency: 97ms -> 34ms
 - Max latency: 308ms -> 38ms
 - Events >50ms: 8.6% -> 0%
 - Frames rendered: +21%
 - Mouse events processed: +9%
 --- a/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc
 +++ b/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc
@@ -2354,7 +2354,7 @@
     case MainThreadTaskQueue::QueueTraits::PrioritisationType::kCompositor:
       return main_thread_only().compositor_priority;
     case MainThreadTaskQueue::QueueTraits::PrioritisationType::kInput:
 -      return TaskPriority::kHighestPriority;
 +      return TaskPriority::kNormalPriority;
     case MainThreadTaskQueue::QueueTraits::PrioritisationType::kBestEffort:
       return TaskPriority::kBestEffortPriority;
     case MainThreadTaskQueue::QueueTraits::PrioritisationType::kRegular: