For a subset of users, SMAPI raises graphics events after drawing to the game's sprite batch will no longer have any effect.

Background

SMAPI draws to the screen in one of two ways:

• At 100% zoom, it draws directly to the output. This seems to work fine for all users.
• At any other zoom, it...
  1. redirects rendering to a temporary render target (e.g. lines 855–858);
  2. draws everything to that target (e.g. line 1306) and ends the sprite batch (e.g. line 1316);
  3. draws that target to the screen and discards it (e.g. lines 1320–1327).

Importantly, it raises OnPostRenderGuiEvent (e.g. line 1307) and OnPostRenderEvent (e.g. line 1315) before ending the sprite batch and discarding the temporary render target.

The issue

For a subset of users:

• Anything drawn in the OnPostRenderGuiEvent, OnPostRenderHudEvent, and OnPostRenderEvent events at a non-100% zoom is invisible. At 100% zoom, it's shown correctly.
• This happens consistently — some users never see the drawn UI at a non-100% zoom; others always see it. There are no reports of inconsistent behaviour.

Notes based on testing:

• For affected users at a non-100% zoom when drawing within graphics event handlers, Game1.spriteBatch.GraphicsDevice.GetRenderTargets() is consistently empty. For unaffected users, it consistently has one value (presumably SGame::Screen).
• Confirmed with the latest version of SDV (1.1.1) and SMAPI (0.40 1.11-3) on Windows. May also occur with SMAPI 0.40 1.11 (based on earlier reports for which I no longer have logs).
• Confirmed that it affects multiple mods (Chests Anywhere 1.6 and 1.7, and Loved Labels 2.0).
• Confirmed that it happens even if only Chests Anywhere in installed, so there's no mod conflict.

Reproducing the issue

I haven't found any way of deliberately causing the issue — it consistently works for some users, consistently breaks for others. However, it's possible to test it.

1. Install the latest version of SMAPI.
2. Install this custom mod created specifically to test this issue (see
   source code).
3. Load a game with zoom level=100%.
4. You should see a red overlay with crosshairs:
   
5. Zoom out.
   • If you're unaffected, you should still see the overlay.
   • If you're affected, the overlay will disappear.

The mod will log relevant metadata to the console.

• For an unaffected user, note that a render target (presumably SGame::Screen) is added when the player zoomes out:

  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=1 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.95 and 1 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.9 and 1 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.85 and 1 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.8 and 1 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.75 and 1 renderTargets
  

• For an affected user, note that the render targets are empty at any zoom level:

  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=1 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.95 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.9 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.85 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.8 and 0 renderTargets
  [MinimalOverlay] Handling OnPostRenderEvent with zoomLevel=0.75 and 0 renderTargets
  

Known affected users

• coffeefox on the Stardew Valley Discord (version 0.40.1.1-3);
• starried via Nexus Mods bug report (version 0.40.1.1);
• TheExile2 via Nexus Mods bug report (possibly; fixed by updating from 0.40.1.1 to 0.40.1.1-3?).

(Thanks coffeefox for letting me use you as a guinea pig, since I'm not affected. 😄)

None of the SMAPI developers can reproduce this, so we need volunteers affected by this issue. Moving this into the backlog until we can find an affected user.

Tested with an affected user; this seems to be fixed in 1.0. 🎊