Previously, with no level loaded in the main editor, and no assets loaded
in the EMotionFX editor, the AnimGraph viewport would only update at 15fps,
even on a 64 core machine.
Digging into this with Pix, I found that EMotionFX's UI would only get
updated for every other call to the ComponentApplication tick.
The Editor's QApplication instance controls how the
`ComponentApplication::OnTick` method is called. This is done in the
`maybeProcessIdle()` method. Generally, I found callstacks like this:
```
EditorQtApplication::maybeProcessIdle()
CCryEditApp::OnIdle()
CCryEditApp::IdleProcessing()
CGameEngine::Update() # ~2.2ms
PhysX::Update() # ~1.8ms
EMotionFX::Update() # ~0.2ms
calls QWidget::update() on all the widgets that change per
frame, only puts update events on the event queue, doesn't
paint anything
AZ::ComponentApplication::TickSystem() # ~25ms
renders the frame with Atom # ~24ms
```
The `maybeProcessIdle()` method is invoked by a QTimer, with a timeout
that changes depending on the application state. If the Editor is in
game mode, it used a timeout of 0, which essentially forced the game to
run at as high an fps as possible. If the Editor application has focus,
it used a timeout of 1ms, asking for the idle processing to happen at
1000 fps. Otherwise, it used a timeout of 10ms, asking for idle
processing at 100 fps.
Those fps targets are not realistic. What happened in this case is that
while the PhysX system was being updated, while the previous
`maybeProcessIdle()` call was still processing, the idle processing
timer would timeout again, and place a timer event on Qt's event queue,
before anything else had a chance to do anything. Only afterward would
EMotionFX's MainWindow::OnTick would be invoked, placing paint events on
Qt's event queue.
The fix for this is to use a single shot timer at the end of each
`maybeProcessIdle()` call. This ensures that any events that are
enqueued during the `maybeProcessIdle()` call are processed prior to the
next call to `maybeProcessIdle()`.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Implement sync interval and refresh rate API for RenderViewportWidget
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Measure actual frame timings in the viewport info overlay.
Takes the median of the sum of (frame end - frame begin) to provide more a more representative view of when frames begin and end.
Note: Until VSync is internally supported by the event loop, this will produce nearly identical frame timings as the frame will spend as much time as needed synchronously waiting on a vblank.
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Make frame timing per-pipeline, wire up refresh rate info to ViewportContext
Signed-off-by: nvsickle <nvsickle@amazon.com>
* POC: Frame limit pipeline rendering
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Switch Editor tick to every 0ms to allow better tick accumulation behavior
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Move RPISystemComponent to the tick bus, remove tick accumulation logic
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Add `AddToRenderTickAtInterval` to RenderPipeline API
This allows a pipeline to update at a set cadence, instead of rendering every frame or being directly told when to tick.
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Make ViewportContext enforce a target framerate
-Adds GetFpsLimit/SetFpsLimit for actively limiting FPS
-Calculates a render tick interval based on vsync and the vps limit and updates the current pipeline
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Add r_fps_limit and ed_inactive_viewport_fps_limit cvars
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Quick null check from a crash I bumped into
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Fix off-by-one on FPS calculation (shouldn't include the not-yet-rendered frame)
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Clarify frame time begin initialization
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Fix TrackView export.
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Address some reviewer feedback, revert RPISystem API change, fix CPU profiler.
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Add g_simulation_tick_rate
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Address review feedback, make frame limit updates event driven
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Remove timestamp update from ComponentApplication::Tick
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Potential Memory Corruption in Release Build
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* @lumberyard-employee-dm suggested code
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* warnings as errors found in VS2022
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* simplifying some strucutres used and fixing a bug
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* some unused fixes for VS2022
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* fix for other platforms
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* fixes check used in unit tests to be case-insensitive
fixes memory leaks/invalid memory operations in AWSCore tests
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
A few 'typedefs' replaced by 'using's
This shouldn't have any functional changes at all, just c++17 modernization
It's a part 1 of a split #2847
Signed-off-by: Nemerle <nemerle5+git@gmail.com>
This disables WM_INPUT forwarding to the input system while in game mode and makes ImGui listen to the synthetic keyboard events from the viewport instead - these synthetic events go through Qt's event system, so will only show up when the viewport "sees" a home key press.
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>