View Issue Details

IDProjectCategoryView StatusLast Update
0002690NoesisGUIC++ SDKpublic2026-04-01 03:01
Reporterdsrour Assigned Tosfernandez  
PrioritynormalSeveritycrash 
Status resolvedResolutionfixed 
Product Version3.2 
Target Version3.2.13Fixed in Version4.0 
Summary0002690: No reliable to recreate views with their contents
Description

More context on this forum post: https://www.noesisengine.com/forums/viewtopic.php?p=16044#p16044

We integrated Noesis into our engine. A bunch of systems make use of Noesis. At anytime, the engine's renderer could reset itself (due to modifying rendering settings or changing graphics API at runtime). When such a reset occurs, we would like to update all view's renderer. However this isn't possible.

In Renderer::Shutdown(), there's a specific comment saying:
// mInitialized is left to true because we only support one Init()/Shutdown() cycle for now

To work around this, when the renderer resets, we do the following for all views:

  • GetContent() from a view
  • Call Shutdown on the view's renderer and release the view
  • Create a new view using the content from GetContent()

This works ok for some views, but for some others (for ex. ones that have animation content), we get an assert in TimeManager::AddMasterClock(...) where the target pointer member is NULL. Ignoring this assert leads to an eventual crash in

Attached are screenshots of the callstack when the assert occurs and when the crash occurs after ignoring the asserts.

Steps To Reproduce

Create a view with some content and try to recreate it:

  • GetContent() from a view
  • Call Shutdown on the view's renderer and release the view
  • Create a new view using the content from GetContent()

I'm unsure exactly why specific views are having issues with this specific logic. I assume it's related to the content having some animations since the assert occurs when transferring animations, which eventually leads to the assert in TimeManager::AddMasterClock(...). Please refer to the screenshots for callstacks.

Attached Files
noesis_crash_assert.png (96,194 bytes)   
noesis_crash_assert.png (96,194 bytes)   
noesis_assert_callstack.png (29,365 bytes)   
noesis_assert_callstack.png (29,365 bytes)   
PlatformAny

Activities

jsantos

jsantos

2024-01-12 12:22

manager   ~0009081

Last edited: 2026-03-03 16:34

Revisions r13182 and r13185 implemented (experimental) support for grabbing RenderDoc captures. This requires hot-swapping the render context, the same scenario that you are trying to solve here. We are doing something similar, creating a new view with the same root content.

The code for recreating the view is this one (Window::RecreateView)

mView = GUI::CreateView(this);
mView->SetScale(mDisplay->GetScale());
mView->SetTessellationMaxPixelError(TessellationMaxPixelError::HighQuality());
mView->SetEmulateTouch(emulateTouch);
mView->SetFlags(mViewFlags);
mView->SetSize(mDisplay->GetClientWidth(), mDisplay->GetClientHeight());
mView->Update(0.0f);

mView->GetRenderer()->Init(context->GetDevice());

In my tests, animations are working fine. Could you please try this when 3.2.3 is released and in case you are still getting an assert attach a XAML here) ?

jsantos

jsantos

2026-04-01 03:01

manager   ~0012136

This was finally fixed in r16933 by adding the following new methods to IRenderer:

/// Detaches the current render device and forces the immediate release of all GPU resources
/// while keeping the CPU-side render tree intact. The renderer enters a suspended state
virtual void DetachDevice() = 0;

/// Attaches a new render device and wakes the renderer from a suspended state.
/// All necessary GPU resources are seamlessly recreated on the new render device
virtual void AttachDevice(RenderDevice* device) = 0;

This will be part of Noesis 4.0

Issue History

Date Modified Username Field Change
2023-09-14 20:56 dsrour New Issue
2023-09-14 20:56 dsrour Tag Attached: C++
2023-09-14 20:56 dsrour File Added: noesis_crash_assert.png
2023-09-14 20:56 dsrour File Added: noesis_assert_callstack.png
2023-09-15 20:16 jsantos Assigned To => sfernandez
2023-09-15 20:16 jsantos Status new => assigned
2024-01-12 12:22 jsantos Note Added: 0009081
2024-01-12 12:22 jsantos Target Version => 3.2.3
2024-01-12 12:22 jsantos Status assigned => feedback
2024-01-12 12:22 jsantos Note Edited: 0009081
2024-01-22 11:47 sfernandez Target Version 3.2.3 => 3.2.4
2024-06-10 11:02 sfernandez Target Version 3.2.4 => 3.2.5
2024-10-24 16:43 sfernandez Target Version 3.2.5 => 3.2.6
2024-11-22 18:19 jsantos Target Version 3.2.6 => 3.2.7
2025-01-20 17:42 jsantos Target Version 3.2.7 => 3.2.8
2025-06-06 12:52 jsantos Target Version 3.2.8 => 3.2.9
2025-10-02 00:49 jsantos Target Version 3.2.9 => 3.2.10
2025-10-20 18:25 jsantos Target Version 3.2.10 => 3.2.11
2026-01-20 19:32 jsantos Target Version 3.2.11 => 3.2.12
2026-03-03 16:34 jsantos Note Edited: 0009081
2026-03-03 16:34 jsantos Note Edited: 0009081
2026-03-04 00:39 jsantos Target Version 3.2.12 => 3.2.13
2026-04-01 03:01 jsantos Note Added: 0012136
2026-04-01 03:01 jsantos Status feedback => resolved
2026-04-01 03:01 jsantos Resolution open => fixed
2026-04-01 03:01 jsantos Fixed in Version => 4.0