How it works?

The secret to WebAP's efficiency lies in its modularity and mathematical approach. The plugin does not attempt to "guess" the cause of lags or blindly slash screen resolution.

The entire system operates as a finely-tuned pipeline consisting of three primary layers: Tracker, Indexer, and Scalers.

Decision Pipeline

The plugin architecture strictly separates data collection, decision-making, and execution.

1. Tracker (Observer)

Every frame, the Tracker gathers raw data regarding frame time and pure CPU time. It calculates an Exponential Moving Average to smooth out random spikes caused by the Garbage Collector (GC) or asset loading.
The Tracker makes no decisions; it merely answers two questions:

• "Are we keeping up with the Target Min FPS?"
• "Which specific subsystem is currently lagging (Bottleneck)?"

2. Indexer (Brain)

The Indexer receives data from the Tracker and decides how to proceed. It is the system's arbiter.
If the FPS drops, the Indexer:

1. Checks if the system is in Cooldown.
2. Evaluates the Anti Yo-Yo Penalty System (see Anti Yo-Yo Penalty for details).
3. Calculates the cost of all available Scalers.
4. Issues a command to the Scaler that will yield maximum performance with minimal visual damage.

3. Scalers (Executors)

Scalers receive commands from the Indexer and perform the heavy lifting. They interface with the Unity API and apply the required settings (reduce resolution, cull layers, disable anti-aliasing).

Bottlenecks: Detecting Bottlenecks Without Thermometers

How does WebAP understand exactly what is failing to handle the load without access to device sensors? We analyze the timing proportions within the engine itself.

• CPU Bottleneck: The Tracker divides the pure processor main thread time by the total frame time. If this ratio exceeds 85%, the conclusion is obvious. The frame is constrained by logic or physics calculations. Decreasing screen resolution or disabling shadows is useless.
• GPU Bottleneck: If the overall FPS is below normal, yet the CPU share is less than 85%, it indicates the processor is idling. The GPU cannot render the frame in time (Fillrate bottleneck, complex shaders, or Overdraw).
• Target Frame Rate: If the average VSync wait time is greater than zero, it signifies that both the processor and the video card are finishing rendering faster than the monitor's refresh rate. The system operates with Performance Headroom, and the Indexer can smoothly increase graphics quality.

Zero-GC: Performance First

A plugin designed to save a game from lagging has no right to lag itself. The WebAP core is engineered with strict memory economy (Zero-GC) in mind along the Hot Path.

• O(1) Ring Buffers: Instead of List<float> and heavy loops in Update, the Tracker utilizes fixed-size arrays (Ring Buffers). Average FPS calculation is executed in constant time.
• Zero Allocations in Update: The core contains no new calls, boxing, or lambdas. There is simply nothing for the Garbage Collector (GC) to clean.
• Delegate Caching: Even for complex tasks (intercepting clicks in WebScaledPhysics2DRaycaster), we abandoned slow reflection (MethodInfo.Invoke) in favor of fast compiled delegates.

Invisibility

Thanks to these optimizations, the overhead for the entire WebAP pipeline is minimal. Your processor will not even notice it is being monitored.