Skip to content

screen flickering v1.11.0 #86

Closed
Closed
screen flickering v1.11.0#86
Labels
bugSomething isn't working

Description

@alexlll-hub
alexlll-hub
opened on Sep 15, 2026

Unfortunately, the screen flickering when moving the mouse (at 10-bit color depth) has returned in this version. The timeline is as follows:
1.6.0 – no flickering at all,
1.9.0 – flickers only when the menu is visible (hiding it stops the flickering),
1.11.0 – flickers regardless.
There is also an issue with saving recorded video: it is impossible to specify a destination folder, and the video is not saved in the automatically created folder.

NeuralScreen.log

Activity

  1. perseval-BLR commented on Sep 15, 2026

    @perseval-BLR
    perseval-BLR
    on Sep 15, 2026
    Owner

    Thanks for the log. v1.12.0 is now available: https://github.com/perseval-BLR/NeuralScreen/releases/tag/v1.12.0

    It contains two fixes taken directly from this report:

    • The flicker log showed SDR Desktop Duplication alternating between DXGI format 10 (FP16) and format 87 (BGRA8), rebuilding the capture bridge each time. v1.12 requests a stable BGRA8 format for SDR capture through DuplicateOutput1, so that format/rebuild loop should be gone on a 10-bit display.
    • The 192 kHz WASAPI endpoint could not be opened by the AAC encoder, which aborted the MP4. Audio is now resampled to AAC at 48 kHz and probed before the real output file is opened. If AAC is unavailable, recording continues as video-only instead of leaving a broken or missing file.

    Recording still saves automatically to the recordings folder; v1.12 does not add a video Save As dialog or custom recording destination yet.

    Could you retest the 10-bit mouse-movement case and one short recording on v1.12.0? If either still fails, please attach the full new log and say whether an MP4 file was created.

  2. alexlll-hub commented on Sep 15, 2026

    @alexlll-hub
    alexlll-hub
    on Sep 15, 2026
    Author

    I checked the latest version; the video now saves correctly, but unfortunately, the flickering hasn't stopped.

    NeuralScreen.log

  3. perseval-BLR commented on Sep 16, 2026

    @perseval-BLR
    perseval-BLR
    on Sep 16, 2026
    Owner

    Your v1.12 log showed that the BGRA-only DuplicateOutput1 request was insufficient: the driver still alternated FP16/BGRA8 1,196 times. v1.13 now uses the original DuplicateOutput BGRA8 conversion for SDR and reserves DuplicateOutput1 for HDR. A real-GPU DDA smoke completed 12 frames with zero bridge rebuilds. Recording remains fixed; keeping this open until the 10-bit flicker is retested on v1.13.

  4. perseval-BLR
    added
    bugSomething isn't working
    on Sep 16, 2026

  5. perseval-BLR commented on Sep 16, 2026

    @perseval-BLR
    perseval-BLR
    on Sep 16, 2026
    Owner

    v1.13.0 is out: NeuralScreen v1.13.0.

    Your log drove the capture fix: the BGRA-only DuplicateOutput1 request was not enough (the driver still alternated FP16/BGRA8 1,196 times), so v1.13 converts SDR through the original IDXGIOutput1::DuplicateOutput to a stable BGRA8 and keeps DuplicateOutput1 for the opt-in HDR path only. Local DDA smoke on the SDR path: 12 frames, zero format-bridge rebuilds.

    Please retest on v1.13.0 and check the log for the format-bridge line:
    [cap] capture format ... -> ... - rebuilding the bridge should not repeat.

    If the flicker is gone, I will close this; if it is not, the fresh NeuralScreen.log plus a diagnostic package (Program tab) is what tells a capture-format problem apart from a display/compositor one.

  6. perseval-BLR
    added a commit that references this issue on Sep 17, 2026

    fix: a 10-bit display cannot flip the capture format every frame (aud…

    110d70a

  7. perseval-BLR commented on Sep 17, 2026

    @perseval-BLR
    perseval-BLR
    on Sep 17, 2026
    Owner

    v1.14.0 is out: NeuralScreen v1.14.0 - please retest.

    Your report has a detail that the v1.13 fix did not cover, and I want to be straight about it rather than let you retest blind.

    The v1.13 change moved SDR capture onto the original DuplicateOutput on the reasoning that DXGI's own 32-bit BGRA conversion is the stronger contract. Another reporter's log then showed that call succeeding and the format still alternating - 1,955 rebuilds in 133 seconds, each one tearing down the whole capture bridge. That reporter is on an HDR-capable display; your case is a 10-bit scan-out, which reaches the same place by a different route.

    So the rule in v1.14.0 is different: a display that can produce a high-colour surface - HDR-capable or a scan-out deeper than 8 bits per colour, which is your case - gets its format pinned through DuplicateOutput1 instead of being offered a choice. The DuplicateOutput path stays for an ordinary 8-bit display, where it works and where the previous behaviour is preserved exactly.

    There is a second change worth knowing about while you retest, because it changed what the capture does on a display like yours: the format is pinned to FP16 first and converted to SDR in the shader. If the flicker is gone but the picture looks different in any way - brightness, contrast, colour - that is the part to tell me about, not something to live with.

    What the log should show now, instead of a repeating bridge line:

    [dda] 10-bit scan-out: FP16 duplication pinned through IDXGIOutput5 (no format flips)

    If you instead get FP16 duplication refused ... falling back to legacy SDR, the driver refused the pinned format and I want that log - it means a different approach is needed for your card.

    The recording-folder half of your report was fixed separately in v1.13 (Settings -> Program holds the output folders now, and the recording folder no longer resets). If it still saves somewhere you did not choose, say so and I will look again.

  8. alexlll-hub commented on Sep 18, 2026

    @alexlll-hub
    alexlll-hub
    on Sep 18, 2026
    Author

    In version 1.4.0, there is no flickering; everything works fine for me. The only issue is that when I take a screenshot, I get just an empty rectangle instead of your program's settings window.

    Image

  9. perseval-BLR commented on Sep 18, 2026

    @perseval-BLR
    perseval-BLR
    on Sep 18, 2026
    Owner

    Thanks - and good to hear the flicker is gone.

    For the empty rectangle: could you describe the exact sequence you did? What I need is small and specific:

    • which menu was open at the moment you pressed the screenshot key - the settings panel, or nothing?
    • did the shot come out as a dark/empty box, or was the panel itself blank inside a normal picture?
    • was NR on at the time?

    The screenshot key saves the frame the worker is currently showing, and if our menu is open it is drawn into that frame on purpose (our overlay is hidden from screen capture, so it has to be added by us). A picture that is entirely empty points at something else - the pipeline being suspended, so there is no processed frame to save yet. The log says which of the two happened.

    If you can, please attach NeuralScreen.log from that session (the folder you run the program from), or the diagnostics ZIP from the settings menu.

  10. perseval-BLR
    added a commit that references this issue on Sep 18, 2026

    fix(hdr): an FP16 frame is not automatically an HDR frame (#99)

    ac3ae21
  11. perseval-BLR
    closed this as completedon Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions