Default‐FPS‐and‐VSync‐Settings‐Analysis - ApertureViewer/Aperture-Viewer GitHub Wiki

Analysis and Recommendation: Default Frame Rate & Synchronization Settings

1. Executive Summary

This document analyzes the optimal default settings for frame rate limitation (FramePerSecondLimit, FSLimitFramerate) and vertical synchronization (RenderVSyncEnable) within Aperture Viewer. These settings are inherited from the Firestorm Viewer codebase. Aperture Viewer also utilizes graphics quality presets defined in featuretable_aperture.txt; changing these presets triggers a full, resource-intensive shader system reload.

The goal is to establish default settings that:

  • Balance visual smoothness with system resource management (load, heat, noise).
  • Prevent screen tearing.
  • Provide computational overhead for stability.
  • Ensure a more consistent perceived performance, especially during demanding operations like graphics preset changes.

Analysis of these factors, common practices in AAA gaming, and the viewer's codebase leads to the following recommendation: Set the default FramePerSecondLimit to 30 FPS, ensure FSLimitFramerate defaults to true (enabled), and ensure RenderVSyncEnable also defaults to true (enabled).

This configuration caps the frame rate at 30 FPS, reducing system strain, while VSync prevents tearing. This baseline also mitigates jarring performance fluctuations experienced during graphics preset changes, contributing to a more stable and predictable user experience. Easy user customization of these settings remains paramount.

2. Introduction: The FPS, Synchronization, and Quality Preset Balancing Act

Real-time 3D rendering applications like Aperture Viewer constantly manage complex trade-offs. High Frames Per Second (FPS) can enhance perceived fluidity but significantly strain system resources (CPU/GPU utilization, leading to increased heat generation and fan noise). Vertical Synchronization (VSync) eliminates screen tearing by synchronizing frame output with the monitor's refresh rate, but it can introduce minor input lag and effectively caps the FPS at the monitor's refresh rate (or a fraction thereof).

Aperture Viewer inherits controls for FPS limiting (the FSLimitFramerate toggle and the FramePerSecondLimit value, primarily from Firestorm's implementation) and VSync (RenderVSyncEnable).

A critical factor in Aperture Viewer is its system of graphics quality presets (e.g., "AP_Level_1_HDR_Foundation", "AP_Level_2_Shadows", etc.), which are defined in featuretable_aperture.txt. As confirmed by the codebase structure (LLFeatureManager::setGraphicsLevel calling LLViewerShaderMgr::instance()->setShaders()), switching between these presets initiates a complete system-wide shader reload. This is a computationally expensive and time-consuming operation.

Defining appropriate default settings for FPS limiting and VSync is therefore crucial not only for establishing a good baseline for performance and resource management during normal operation but also for managing perceived performance consistency during these demanding graphics preset changes.

3. Rationale for Default Limits and Synchronization

Several factors motivate establishing constrained defaults for FPS and enabling VSync by default:

  • System Load and Thermal Management: Uncapped or very high frame rates can push CPU and GPU utilization to their maximum, leading to increased system heat and fan noise. Limiting FPS significantly alleviates this, resulting in a quieter and cooler system.
  • Computational Overhead for Stability: A capped FPS ensures that some system resources (CPU/GPU cycles) remain available. This overhead can contribute to overall system stability, allow background tasks to run more smoothly, and help the viewer handle sudden rendering spikes (e.g., when many avatars or complex objects rez in) more gracefully.
  • Power Consumption: Reduced system load directly translates to lower power consumption, which is beneficial for all users and particularly relevant for laptop users.
  • User Experience and Quality of Life: For many users, a quieter and cooler system is preferable to achieving the absolute maximum possible FPS, especially if that maximum comes at the cost of excessive fan noise or system heat. VSync provides a tear-free image, which significantly improves visual quality and immersion.
  • Consistency Across Varying Loads: A lower target FPS (e.g., 30 FPS) means that when the viewer encounters a complex scene or a demanding operation, the drop in frame rate is perceived as less dramatic than if it were dropping from a much higher, uncapped rate. This leads to a feeling of greater consistency.
  • Managing Graphics Preset Changes: This is a key consideration for Aperture Viewer. The viewer reloads all shaders when a user switches between different graphics quality presets. This is an extremely demanding operation that temporarily causes a significant performance dip.
    • If the viewer is running at an uncapped or very high FPS, this dip can be very jarring (e.g., from 100+ FPS down to single digits).
    • With a lower baseline FPS cap (e.g., 30 FPS), the frame rate starts at 30 FPS, will still drop during the shader reload, but then aims to settle back at or near 30 FPS once the new preset is active. The perceived drop from the steady state is much smaller, making the transition feel less disruptive and more stable, even though the underlying shader reload process is still intensive.
  • Target Audience Considerations: Providing sensible, resource-friendly defaults offers a safer and less potentially overwhelming out-of-the-box experience, especially for users who may not be inclined to immediately dive into advanced settings.

4. Analysis of Default FPS Options

(This section previously analyzed 15, 30, 60, and Uncapped FPS targets. The conclusion that 30 FPS offers the best compromise for a capped target remains valid, especially strengthened by the rationale in section 3 regarding managing graphics preset changes.)

A 30 FPS target provides a good balance:

  • It's significantly smoother than 15 FPS for most interactions.
  • It's generally achievable on a wider range of hardware than 60 FPS, especially with modern Second Life graphics features enabled.
  • It drastically reduces system load compared to 60 FPS or uncapped rates.
  • It provides a stable baseline that makes performance dips during intensive operations (like preset changes) less jarring.

5. Vertical Synchronization (RenderVSyncEnable)

  • Setting Name (Debug): RenderVSyncEnable
  • Type: Boolean
  • UI Label Example: "Vertical Sync (VSync)"
  • Comment in Settings File: "Update frames between display scans (FALSE = Update frames as fast as possible)."
  • Current Default Value (and Recommended): 1 (true, Enabled).
  • Function: When enabled, VSync synchronizes the viewer's frame rendering output with the monitor's vertical refresh cycle (e.g., 60Hz, 120Hz, 144Hz).
    • Primary Benefit: Prevents screen tearing, an artifact where parts of multiple frames are shown on screen simultaneously, creating a visible horizontal "tear" in the image.
    • Side Effects:
      • Caps the maximum achievable FPS to the monitor's refresh rate (or a divisor of it, like 30 FPS on a 60Hz monitor if the system can't maintain 60 FPS).
      • Can, in some cases, introduce a small amount of input lag, though this is often negligible for non-competitive gameplay.
  • Code Implementation: The RenderVSyncEnable setting is typically checked during window creation (e.g., LLWindowManager::createWindow) to set the appropriate swap interval for the graphics context. It's also often linked to an event handler (handleVSyncChanged) that might interact with other FPS-related settings like TargetFPS and is re-applied post-login, especially with display libraries like SDL2.

Recommendation: Enabling RenderVSyncEnable by default is strongly recommended for a visually stable, tear-free experience out-of-the-box, which aligns with common practice in many applications and games.

6. Inherited FPS Limiter Implementation (Firestorm Code)

Aperture Viewer inherits an FPS limiting mechanism from the Firestorm codebase.

  • Settings:
    • FSLimitFramerate (Boolean): Master toggle to enable/disable the FPS limiter. (UI Label: "Limit Frame Rate")
    • FramePerSecondLimit (F32/Integer): The target maximum FPS when the limiter is enabled. (UI Label: "Maximum Frame Rate (FPS)")
  • Implementation: The core logic is typically found within the main application loop (e.g., LLAppViewer::doFrame).
    • It calculates the desired time per frame based on FramePerSecondLimit.
    • It measures the actual time taken for the previous frame.
    • If the frame rendered faster than the target, it introduces a delay (e.g., via yield_timeslice() or sleep()) to slow down the next frame's start, effectively capping the FPS.
  • Current Default Values (Firestorm): Typically FSLimitFramerate is true (enabled), and FramePerSecondLimit defaults to 60.

7. Interaction Between VSync, FPS Limiter, and Preset Changes

Understanding how these systems interact is key:

  • VSync and Limiter Interaction (Recommended Defaults Scenario):
    • If RenderVSyncEnable is ON (e.g., on a 60Hz monitor, capping at 60 FPS).
    • And FSLimitFramerate is ON with FramePerSecondLimit set to 30 FPS.
    • Outcome: The FramePerSecondLimit (30 FPS) will be the binding constraint. The viewer will aim for 30 FPS. VSync will still operate to prevent tearing, but it won't be the primary factor determining the frame rate unless the monitor's refresh rate is lower than 30Hz (very unlikely).
  • Impact of Graphics Preset Changes: When a user selects a different graphics quality preset from the featuretable_aperture.txt via the APS Gen Tab, the LLFeatureManager::setGraphicsLevel function is called. This, in turn, typically calls LLViewerShaderMgr::instance()->setShaders(), initiating a reload and recompilation of all active shaders. This process is resource-intensive and causes a temporary but significant drop in performance.
    • Without an FPS Cap (or with a high cap like 60 FPS): If the viewer was running at, say, 80-100+ FPS, the drop during shader reload might be to 5-10 FPS. This >70 FPS fluctuation is highly noticeable and can feel like a stall or freeze. After the reload, the FPS might settle at a new, potentially different, high rate.
    • With a 30 FPS Cap: The viewer starts at a steady 30 FPS. During the shader reload, the FPS will still drop (potentially to the same 5-10 FPS momentarily because the task is inherently heavy). However, because the starting point was 30 FPS, the perceived drop is much smaller (e.g., 30 FPS -> 10 FPS vs. 100 FPS -> 10 FPS). When the reload completes, the FPS will aim to return to the 30 FPS cap. This makes the entire preset switching experience feel significantly less disruptive and more stable, even though the underlying shader reload is still just as intensive.

8. Technical Precedent: AAA Gaming Practices

Many console games and some PC titles have historically targeted or offered 30 FPS modes, especially for graphically intensive experiences. While 60 FPS or higher is often preferred for fluidity, 30 FPS is widely accepted as a playable and smooth experience if consistent, and it allows for higher visual fidelity on constrained hardware. A locked 30 FPS is often perceived as better than a wildly fluctuating frame rate that averages higher but has deep drops.

9. Discussion and Synthesis

The need for a sensible default configuration for frame rate and synchronization is underscored by the resource demands of both standard rendering operations and the particularly intensive process of graphics preset changes unique to how viewers like Aperture manage quality levels.

  • Setting FramePerSecondLimit to 30 FPS (with FSLimitFramerate enabled) directly addresses the goals of reducing baseline system load, heat, and fan noise. Crucially, it provides a more stable perceived performance baseline, making the inevitable performance dips during demanding operations like graphics preset switching less jarring to the user.
  • Enabling RenderVSyncEnable by default ensures a higher baseline visual quality by preventing screen tearing, which can be distracting.
  • This combined default configuration leverages existing mechanisms inherited from the Firestorm codebase to prioritize stability, sensible resource management, and visual integrity for the out-of-the-box experience.

10. Recommendation (Final)

Based on the comprehensive analysis of performance trade-offs, user experience factors (including the impact of graphics preset switching), precedents in AAA gaming, visual quality considerations (VSync), and the specific rendering pipeline and settings mechanisms inherited and utilized by Aperture Viewer:

It is strongly recommended to configure the default settings within Aperture Viewer as follows:

  1. Set the default value of RenderVSyncEnable to 1 (true). (This confirms the existing and generally good default).
  2. Ensure the default value of FSLimitFramerate remains 1 (true). (This confirms the existing and sensible default).
  3. Change the default value of FramePerSecondLimit from the common upstream 60 to 30. (This is the key proposed change for Aperture Viewer).

This default configuration establishes a 30 FPS frame rate limit via the existing Firestorm limiter mechanism and enables VSync for tear prevention. This combination provides a stable, resource-friendly, and visually clean baseline experience that also significantly mitigates perceived performance swings during graphics quality adjustments within the APS.

11. Implementation Considerations (UI and User Control)

Clear UI presentation and user control over these defaults are essential:

  1. Setting Discoverability & Clarity:
    • The settings should be clearly labeled and logically grouped within the graphics preferences, ideally on the APS Gen Tab.
    • RenderVSyncEnable: Suggested UI Label: "Vertical Sync (VSync)" (Checkbox).
    • FSLimitFramerate: Suggested UI Label: "Enable FPS Limit" (Checkbox).
    • FramePerSecondLimit: Suggested UI Label: "Max FPS" (Slider/Input field), which should be active/enabled only if "Enable FPS Limit" is checked.
  2. Informative Tooltips:
    • VSync: "Synchronizes frame rendering with your monitor's refresh rate to eliminate screen tearing. Recommended: Enabled."
    • Enable FPS Limit: "Enables a maximum frame rate limit. This can reduce system load, heat, and fan noise, and improve perceived stability during graphics setting changes. Disable for potentially higher but less stable FPS."
    • Max FPS: "Sets the desired upper FPS limit when 'Enable FPS Limit' is checked. Lower values (e.g., 30) reduce system load but may decrease perceived smoothness for some users. Higher values increase fluidity but also increase system load. Note: VSync may also limit your FPS depending on your monitor's refresh rate."
  3. User Overrides: Users must be able to easily toggle VSync and the FPS Limiter on/off, and select their own custom FPS limit if they choose to disable the default or prefer a different cap. These settings should be saved per user.

12. Conclusion

Choosing default rendering settings requires a careful balance between desired fluidity, visual quality, system resource utilization, and the overall user experience during various in-viewer operations, including computationally intensive tasks like changing graphics quality presets. By defaulting RenderVSyncEnable to true, FSLimitFramerate to true, and modifying the default FramePerSecondLimit to 30, Aperture Viewer can establish an out-of-the-box baseline that prioritizes system stability, reduced resource consumption, tear-free visuals, and a less jarring user experience during graphics adjustments. This configuration responsibly leverages inherited mechanisms, while ensuring that clear UI customization for these settings remains critical for user empowerment and choice.