Tests are passing on macOS with this patch. I did a little extra looking through mmap manpages to see if any other flags could be used, but this was the only one.

I had the same need, and ended up just patching a vendored copy of loom in the meantime:

diff -adupwr /Users/parasyte/other-projects/loom/src/model.rs loom/src/model.rs
--- /Users/parasyte/other-projects/loom/src/model.rs	2020-09-21 02:58:40.000000000 -0700
+++ loom/src/model.rs	2020-09-21 02:06:02.000000000 -0700
@@ -5,7 +5,7 @@ use std::path::PathBuf;
 use std::sync::Arc;
 use std::time::{Duration, Instant};

-const DEFAULT_MAX_THREADS: usize = 4;
+const DEFAULT_MAX_THREADS: usize = 8;
 const DEFAULT_MAX_BRANCHES: usize = 1_000;

 /// Configure a model
diff -adupwr /Users/parasyte/other-projects/loom/src/rt/mod.rs loom/src/rt/mod.rs
--- /Users/parasyte/other-projects/loom/src/rt/mod.rs	2020-10-21 23:40:59.000000000 -0700
+++ loom/src/rt/mod.rs	2020-09-21 02:06:02.000000000 -0700
@@ -57,7 +57,7 @@ mod vv;
 pub(crate) use self::vv::VersionVec;

 /// Maximum number of threads that can be included in a model.
-pub(crate) const MAX_THREADS: usize = 4;
+pub(crate) const MAX_THREADS: usize = 8;

 /// Maximum number of atomic store history to track per-cell.
 pub(crate) const MAX_ATOMIC_HISTORY: usize = 7;

• Incorporates changes for:
  • https://github.com/rust-lang/rust/pull/76993
  • https://github.com/rust-lang/rust/pull/77315

I'll have to get a VM going to try a repro. I'm on macOS and it's all working correctly here.

This is pretty unusual. The swapchain is recreated by the resize handler: https://github.com/parasyte/pixels/blob/e5f92519f17026a9f7e4821c5e9fc72895cdc857/src/lib.rs#L220-L230

This could actually be a race condition between resize and render. The event loop in the example uses winit_input_helper = "0.6.0" which consumes the Event type when updating the state. This forces our hand to handle the render before resize. The latest version of this crate takes &Event, so we can actually reorder these.

@schnippl0r Try this patch, let me know if it helps:

diff --git a/examples/minimal-winit/Cargo.toml b/examples/minimal-winit/Cargo.toml
index 7acbc4e..758eddf 100644
--- a/examples/minimal-winit/Cargo.toml
+++ b/examples/minimal-winit/Cargo.toml
@@ -13,5 +13,5 @@ default = ["optimize"]
 env_logger = "0.7.1"
 log = "0.4.8"
 pixels = { path = "../.." }
-winit = "0.22.0"
-winit_input_helper = "0.6.0"
+winit = "0.23.0"
+winit_input_helper = "0.8.0"
diff --git a/examples/minimal-winit/src/main.rs b/examples/minimal-winit/src/main.rs
index fcaeff7..d1ecdf0 100644
--- a/examples/minimal-winit/src/main.rs
+++ b/examples/minimal-winit/src/main.rs
@@ -43,21 +43,8 @@ fn main() -> Result<(), Error> {
     let mut world = World::new();
 
     event_loop.run(move |event, _, control_flow| {
-        // Draw the current frame
-        if let Event::RedrawRequested(_) = event {
-            world.draw(pixels.get_frame());
-            if pixels
-                .render()
-                .map_err(|e| error!("pixels.render() failed: {}", e))
-                .is_err()
-            {
-                *control_flow = ControlFlow::Exit;
-                return;
-            }
-        }
-
         // Handle input events
-        if input.update(event) {
+        if input.update(&event) {
             // Close events
             if input.key_pressed(VirtualKeyCode::Escape) || input.quit() {
                 *control_flow = ControlFlow::Exit;
@@ -73,6 +60,19 @@ fn main() -> Result<(), Error> {
             world.update();
             window.request_redraw();
         }
+
+        // Draw the current frame
+        if let Event::RedrawRequested(_) = event {
+            world.draw(pixels.get_frame());
+            if pixels
+                .render()
+                .map_err(|e| error!("pixels.render() failed: {}", e))
+                .is_err()
+            {
+                *control_flow = ControlFlow::Exit;
+                return;
+            }
+        }
     });
 }
 

It looks like std needs to be built with ASan, as well. Building with the build-std flag causes the workaround to fail. The executable will trigger both stack-use-after-scope and stack-use-after-return errors with build-std. At least it does on macOS.

I hit this as well. More info in https://github.com/rust-lang/rust/issues/39610

Workaround is using -Z build-std

minimal repro:

use loom::thread;

fn main() {
    loom::model(|| {
        thread::spawn(|| ()).join().unwrap();
    });
}

<details><summary>Debug session log on macOS</summary>

$ RUSTFLAGS='-Zsanitizer=address' cargo build
    Updating crates.io index
   Compiling semver-parser v0.7.0
   Compiling cc v1.0.60
   Compiling libc v0.2.77
   Compiling log v0.4.11
   Compiling cfg-if v0.1.10
   Compiling scoped-tls v1.0.0
   Compiling semver v0.9.0
   Compiling rustc_version v0.2.3
   Compiling generator v0.6.22
   Compiling loom v0.3.5
   Compiling loom-asan-test v0.1.0 (/Users/parasyte/other-projects/loom-asan-test)
    Finished dev [unoptimized + debuginfo] target(s) in 8.19s

$ lldb target/debug/loom-asan-test
(lldb) target create "target/debug/loom-asan-test"
Current executable set to '/Users/parasyte/other-projects/loom-asan-test/target/debug/loom-asan-test' (x86_64).

(lldb) r
Process 40279 launched: '/Users/parasyte/other-projects/loom-asan-test/target/debug/loom-asan-test' (x86_64)
Completed in 1 iterations
==40279==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffeefc00000; bottom 0x000104106000; size: 0x7ffdebafa000 (140728557608960)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
=================================================================
==40279==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000104107b28 at pc 0x0001003ccd4d bp 0x000104107600 sp 0x000104106dc0
READ of size 168 at 0x000104107b28 thread T0
    #0 0x1003ccd4c in wrap_memmove+0x16c (librustc-nightly_rt.asan.dylib:x86_64+0x17d4c)

Address 0x000104107b28 is a wild pointer.
SUMMARY: AddressSanitizer: stack-use-after-scope (librustc-nightly_rt.asan.dylib:x86_64+0x17d4c) in wrap_memmove+0x16c
Shadow bytes around the buggy address:
  0x100020820f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100020820f60: f1 f1 f1 f1 f8[f8]f2 f2 00 00 f3 f3 00 00 00 00
  0x100020820f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100020820fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
2020-09-21 01:30:56.687976-0700 loom-asan-test[40279:9567333] ==40279==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffeefc00000; bottom 0x000104106000; size: 0x7ffdebafa000 (140728557608960)
2020-09-21 01:30:56.688357-0700 loom-asan-test[40279:9567333] False positive error reports may follow
2020-09-21 01:30:56.688365-0700 loom-asan-test[40279:9567333] For details see https://github.com/google/sanitizers/issues/189
2020-09-21 01:30:56.688371-0700 loom-asan-test[40279:9567333] =================================================================
2020-09-21 01:30:56.688377-0700 loom-asan-test[40279:9567333] ==40279==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000104107b28 at pc 0x0001003ccd4d bp 0x000104107600 sp 0x000104106dc0
2020-09-21 01:30:56.688383-0700 loom-asan-test[40279:9567333] READ of size 168 at 0x000104107b28 thread T0
2020-09-21 01:30:56.688388-0700 loom-asan-test[40279:9567333]     #0 0x1003ccd4c in wrap_memmove+0x16c (librustc-nightly_rt.asan.dylib:x86_64+0x17d4c)
2020-09-21 01:30:56.688393-0700 loom-asan-test[40279:9567333]
2020-09-21 01:30:56.688399-0700 loom-asan-test[40279:9567333] Address 0x000104107b28 is a wild pointer.
2020-09-21 01:30:56.688405-0700 loom-asan-test[40279:9567333] SUMMARY: AddressSanitizer: stack-use-after-scope (librustc-nightly_rt.asan.dylib:x86_64+0x17d4c) in wrap_memmove+0x16c
2020-09-21 01:30:56.688410-0700 loom-asan-test[40279:9567333] Shadow bytes around the buggy address:
2020-09-21 01:30:56.688442-0700 loom-asan-test[40279:9567333]   0x100020820f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688447-0700 loom-asan-test[40279:9567333]   0x100020820f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688452-0700 loom-asan-test[40279:9567333]   0x100020820f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688472-0700 loom-asan-test[40279:9567333]   0x100020820f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688477-0700 loom-asan-test[40279:9567333]   0x100020820f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688503-0700 loom-asan-test[40279:9567333] =>0x100020820f60: f1 f1 f1 f1 f8[f8]f2 f2 00 00 f3 f3 00 00 00 00
2020-09-21 01:30:56.688508-0700 loom-asan-test[40279:9567333]   0x100020820f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688514-0700 loom-asan-test[40279:9567333]   0x100020820f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688519-0700 loom-asan-test[40279:9567333]   0x100020820f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688525-0700 loom-asan-test[40279:9567333]   0x100020820fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688530-0700 loom-asan-test[40279:9567333]   0x100020820fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2020-09-21 01:30:56.688535-0700 loom-asan-test[40279:9567333] Shadow byte legend (one shadow byte represents 8 application bytes):
2020-09-21 01:30:56.688541-0700 loom-asan-test[40279:9567333]   Addressable:           00
2020-09-21 01:30:56.688547-0700 loom-asan-test[40279:9567333]   Partially addressable: 01 02 03 04 05 06 07
2020-09-21 01:30:56.688552-0700 loom-asan-test[40279:9567333]   Heap left redzone:       fa
2020-09-21 01:30:56.688557-0700 loom-asan-test[40279:9567333]   Freed heap region:       fd
2020-09-21 01:30:56.688561-0700 loom-asan-test[40279:9567333]   Stack left redzone:      f1
2020-09-21 01:30:56.688567-0700 loom-asan-test[40279:9567333]   Stack mid redzone:       f2
2020-09-21 01:30:56.688572-0700 loom-asan-test[40279:9567333]   Stack right redzone:     f3
2020-09-21 01:30:56.688577-0700 loom-asan-test[40279:9567333]   Stack after return:      f5
2020-09-21 01:30:56.688582-0700 loom-asan-test[40279:9567333]   Stack use after scope:   f8
2020-09-21 01:30:56.688601-0700 loom-asan-test[40279:9567333]   Global redzone:          f9
2020-09-21 01:30:56.688605-0700 loom-asan-test[40279:9567333]   Global init order:       f6
2020-09-21 01:30:56.688629-0700 loom-asan-test[40279:9567333]   Poisoned by user:        f7
2020-09-21 01:30:56.688633-0700 loom-asan-test[40279:9567333]   Container overflow:      fc
2020-09-21 01:30:56.688638-0700 loom-asan-test[40279:9567333]   Array cookie:            ac
2020-09-21 01:30:56.688651-0700 loom-asan-test[40279:9567333]   Intra object redzone:    bb
2020-09-21 01:30:56.688657-0700 loom-asan-test[40279:9567333]   ASan internal:           fe
2020-09-21 01:30:56.688676-0700 loom-asan-test[40279:9567333]   Left alloca redzone:     ca
2020-09-21 01:30:56.688681-0700 loom-asan-test[40279:9567333]   Right alloca redzone:    cb
2020-09-21 01:30:56.688704-0700 loom-asan-test[40279:9567333]   Shadow gap:              cc
==40279==ABORTING
Process 40279 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff6b0ad33a libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff6b0ad33a <+10>: jae    0x7fff6b0ad344            ; <+20>
    0x7fff6b0ad33c <+12>: movq   %rax, %rdi
    0x7fff6b0ad33f <+15>: jmp    0x7fff6b0a7629            ; cerror_nocancel
    0x7fff6b0ad344 <+20>: retq
Target 0: (loom-asan-test) stopped.

(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6b0ad33a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6b169e60 libsystem_pthread.dylib`pthread_kill + 430
    frame #2: 0x00007fff6b034808 libsystem_c.dylib`abort + 120
    frame #3: 0x0000000100417176 librustc-nightly_rt.asan.dylib`__sanitizer::Abort() + 70
    frame #4: 0x0000000100416ab4 librustc-nightly_rt.asan.dylib`__sanitizer::Die() + 196
    frame #5: 0x00000001003fe954 librustc-nightly_rt.asan.dylib`__asan::ScopedInErrorReport::~ScopedInErrorReport() + 420
    frame #6: 0x00000001003fe1ee librustc-nightly_rt.asan.dylib`__asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) + 1198
    frame #7: 0x00000001003ccd6c librustc-nightly_rt.asan.dylib`wrap_memmove + 396
    frame #8: 0x00007fff6b197b84 libunwind.dylib`unw_init_local + 33
    frame #9: 0x00007fff6b198563 libunwind.dylib`unwind_phase2 + 41
    frame #10: 0x00007fff6b19be79 libunwind.dylib`_Unwind_Resume + 51
    frame #11: 0x0000000100067fed loom-asan-test`generator::yield_::yield_::h44b204ac82d88f36(v=<unavailable>) at yield_.rs:0:1
    frame #12: 0x000000010002955a loom-asan-test`loom::rt::scheduler::spawn_threads::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h78704182e038d361((null)=closure-0 @ 0x0000000104108220) at scheduler.rs:138:56
    frame #13: 0x00000001001193b6 loom-asan-test`generator::gen_impl::GeneratorImpl$LT$A$C$T$GT$::init_code::_$u7b$$u7b$closure$u7d$$u7d$::h9b912bd353b5bf3b at gen_impl.rs:308:21
    frame #14: 0x00000001000e54fc loom-asan-test`generator::stack::StackBox$LT$F$GT$::call_once::h30684f411b2ff6b2(data=0x0000000104108e80) at mod.rs:135:13
    frame #15: 0x0000000100121407 loom-asan-test`generator::stack::Func::call_once::h4daec637ff184991(self=Func @ 0x0000000104108620) at mod.rs:117:9
    frame #16: 0x0000000100138f4d loom-asan-test`generator::gen_impl::gen_init::_$u7b$$u7b$closure$u7d$$u7d$::h83bb20a1b69e36a1 at gen_impl.rs:513:9
    frame #17: 0x000000010012b57c loom-asan-test`core::ops::function::FnOnce::call_once::h1e673fc2980aed3f((null)=closure-0 @ 0x0000000104108820, (null)=<unavailable>) at function.rs:227:5
    frame #18: 0x0000000100126e1a loom-asan-test`std::panicking::try::do_call::hff3b691df2061b12(data="�\x8f\x10\x04\x01") at panicking.rs:381:40
    frame #19: 0x0000000100127b9d loom-asan-test`__rust_try + 29
    frame #20: 0x0000000100126b18 loom-asan-test`std::panicking::try::hf89589518d2a7178(f=closure-0 @ 0x0000000104108b20) at panicking.rs:345:19
    frame #21: 0x000000010012b2a1 loom-asan-test`std::panic::catch_unwind::hd2813c5b6faf7255(f=closure-0 @ 0x0000000104108ba8) at panic.rs:382:14
    frame #22: 0x00000001001387f8 loom-asan-test`generator::gen_impl::gen_init::hc5eedddfe516064c((null)=0, f=0x0000000104108fa0) at gen_impl.rs:527:25

</details>

AFAICT, this is caused by the way the generator crate is used. The error can be worked around by enabling the detect_stack_use_after_return option:

$ RUSTFLAGS='-Zsanitizer=address' ASAN_OPTIONS=detect_stack_use_after_return=1 cargo run
   Compiling semver-parser v0.7.0
   Compiling cc v1.0.60
   Compiling libc v0.2.77
   Compiling log v0.4.11
   Compiling semver v0.9.0
   Compiling rustc_version v0.2.3
   Compiling generator v0.6.22
   Compiling loom v0.3.5
   Compiling loom-asan-test v0.1.0 (/Users/parasyte/other-projects/loom-asan-test)
    Finished dev [unoptimized + debuginfo] target(s) in 6.77s
     Running `target/debug/loom-asan-test`
Completed in 1 iterations
==42679==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffee4596000; bottom 0x00010fdb5000; size: 0x7ffdd47e1000 (140728168484864)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189

The above warning is also printed on Linux, even without the macOS workaround.

• Was running every minute of the day on Sunday, whoops!

• Was running every minute of the day on Sunday, whoops!

• The old one had artifacts on the window border

• The old one had artifacts on the window border

FWIW, I added an example that shows using raqote to animate some vectors using pixels: https://github.com/parasyte/pixels/tree/master/examples/raqote-winit The example uses winit for window handling, input, and event loop.

• Closes #90

I'm not super happy with this, but it's good enough for now.

imgui is notoriously bad about color space management. See https://github.com/ocornut/imgui/issues/578 This PR uses the same hack that I added to the imgui-gfx support crate a few years ago.

The other issue is that I originally wanted to draw the windows and GUI elements in the prepare method. This turned out to be impossible because of the lifetime requirement on imgui::Ui. The compromise I came up with was moving all drawing to the render method so the Ui type doesn't have to cross exclusive borrow boundaries, resolving all lifetime issues.

Hey, I'm pretty new to graphics programming and wgpu. I was wondering how you'd go about adding UI while using pixels?

Would a library like Iced work, since it has wgpu support?

Is this where you'd use render passes?

The png crate pulls in some dependencies that I don't need. It would be nice to disable it with a feature flag.

I created an example using raqote with pixels: https://github.com/parasyte/pixels/pull/118

This should go back to default, right? Which is Reactive.

Here's a short list of readable fonts that have "rounded features":

• Titillium Web
• Maven Pro
• Antic
• Carme

All of these are available under the terms of the OFL.

And rebased on master.

@emilk I force-pushed a new patch for this. Tested on Windows and macOS. I haven't tested on Linux (X11 or Wayland).

Neither event handler RedrawRequested or RedrawEventsCleared worked on both platforms, so I decided to use the latter for Windows and the former (original event) for all other platforms. I wasn't able to come up with a good pattern for platform-specific event handling, so I moved all of the code into a closure. It hurts diff readability, but I don't know of another way to solve that.

I also had to add another request_redraw() call for Continuous mode to work on macOS.

On Windows 10, both modes act completely identically. No updates occur unless an event is delivered (especially moving the mouse cursor). I believe this is caused by a bug in winit. See https://github.com/rust-windowing/winit/issues/987 and https://github.com/rust-windowing/winit/issues/1619

Continuous mode does work correctly on macOS. And this PR also breaks Reactive mode on macOS. So I'll have to go back to the drawing board on this.

@aptalca The original preferences.xml is included in the OP. No token or other claims were set there.

I'm not sure what environment variable you are talking about, but it wouldn't have been anything that I configured.

That's an authentication error. Check or change your password? My account was originally logged in with google, and I had to add a password to my account to use the script.

This saves about 46 KB overall, and improves the text quality (IMHO).

Before:

After:

As you can see, Oxygen is not the most ideal font. It only supports the Latin character set. Still feels worth the increase in readability and decrease in executable size.

Also this looks similar to #987

Seeing the same problem, but request_redraw is called from within RedrawEventsCleared. Trying to conditionally spin the event loop with ControlFlow::Wait.

The primary change here is that the winit control flow is set according to RunMode, and not assumed to be Wait. I also had to change the event handler to RedrawEventsCleared.

Prior to this patch, the Continuous run mode didn't work correctly in the glium backend. But it does work as expected in the web backend.

Here's talk of render subpasses in webgpu: https://github.com/gpuweb/gpuweb/issues/393 This is something that the noise renderer in the custom shader example could make use of. But I still don't believe this will be usable in general cases. Taking the shadow and water examples again as illustration.

I'm getting a multitude of errors when running the minimal-winit example with gdb, with the latest version of pixels. I'm not sure whether this is actually the fault of pixels, or one of its dependencies.

I'm running Windows 10, and I've tried running both MINGW's version of gdb on the minimal-winit.exe binary, as well as debugging via VS Code using cppvsdbg.

In both cases, I first get an error of the form

warning: D3D12 WARNING: ID3D12Device::CreateConstantBufferView: Resource 0x000001BA43D327C0:'Unnamed ID3D12Resource Object' and 1 other resources contain the GPU Virtual Address range [0x0000000076460000, 0x00000000764600ff] on a Heap (0x000001BA43D2F7B0:'Unnamed ID3D12Heap Object').  This may be OK as long as all of these resources are in the same state however developer probably did not intend to make use of this behavior. [ STATE_CREATION WARNING #926: HEAP_ADDRESS_RANGE_INTERSECTS_MULTIPLE_BUFFERS]

I then continuously get errors of the form

D3D12 ERROR: ID3D12GraphicsCommandList::Reset: Reset fails because the command list was not closed. [ EXECUTION ERROR #544: COMMAND_LIST_OPEN]
D3D12 ERROR: ID3D12CommandAllocator::Reset: The command allocator cannot be reset because a command list is currently being recorded with the allocator. [ EXECUTION ERROR #543: COMMAND_ALLOCATOR_CANNOT_RESET]

When debugging via VS Code, exceptions are thrown:

Exception thrown at 0x00007FFDB45FA799 in minimal-winit.exe: Microsoft C++ exception: _com_error at memory location 0x00000067B6CEEE88.

When checking the option to break on exceptions, the program stops at a location with the following call stack:

KernelBase.dll!00007ffdb45fa799() (Unknown Source:0)
ucrtbase.dll!00007ffdb54fb6fd() (Unknown Source:0)
D3D12.dll!00007ffd74875c0c() (Unknown Source:0)
minimal-winit.exe!winapi::um::d3d12::ID3D12CommandAllocator::Reset() Line 217 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winapi-0.3.9\src\macros.rs:217)
minimal-winit.exe!gfx_backend_dx12::command::{{impl}}::begin(gfx_backend_dx12::command::CommandBuffer * self, gfx_hal::command::CommandBufferFlags _flags, gfx_hal::command::CommandBufferInheritanceInfo<gfx_backend_dx12::Backend>) Line 1165 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx-backend-dx12-0.5.8\src\command.rs:1165)
minimal-winit.exe!gfx_hal::command::CommandBuffer::begin_primary<gfx_backend_dx12::command::CommandBuffer,gfx_backend_dx12::Backend>(gfx_backend_dx12::command::CommandBuffer * self, gfx_hal::command::CommandBufferFlags flags) Line 123 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx-hal-0.5.3\src\command\mod.rs:123)
minimal-winit.exe!wgpu_core::hub::Global<wgpu_core::hub::IdentityManagerFactory>::device_create_command_encoder<wgpu_core::hub::IdentityManagerFactory,gfx_backend_dx12::Backend>(wgpu_core::id::Id<wgpu_core::device::Device<gfx_backend_empty::Backend>> self, wgpu_types::CommandEncoderDescriptor * device_id, core::marker::PhantomData<wgpu_core::id::Id<wgpu_core::command::CommandBuffer<gfx_backend_empty::Backend>>> desc) Line 1356 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-core-0.5.6\src\device\mod.rs:1356)
minimal-winit.exe!wgpu_native::device::wgpu_device_create_command_encoder(wgpu_core::id::Id<wgpu_core::device::Device<gfx_backend_empty::Backend>> device_id, core::option::Option<wgpu_types::CommandEncoderDescriptor*> desc) Line 302 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.5.1\src\device.rs:302)
minimal-winit.exe!wgpu::Device::create_command_encoder(wgpu::CommandEncoderDescriptor * self) Line 702 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.5.2\src\lib.rs:702)
minimal-winit.exe!pixels::Pixels::render_with<closure-0>(pixels::{{impl}}::render::closure-0 self) Line 283 (d:\Dropbox\Programming\rust\pixelsnew2\src\lib.rs:283)
minimal-winit.exe!pixels::Pixels::render() Line 235 (d:\Dropbox\Programming\rust\pixelsnew2\src\lib.rs:235)
minimal-winit.exe!minimal_winit::main::{{closure}}(minimal_winit::main::closure-0 * event, winit::event::Event<()>, winit::event_loop::EventLoopWindowTarget<()> * control_flow, winit::event_loop::ControlFlow *) Line 50 (d:\Dropbox\Programming\rust\pixelsnew2\examples\minimal-winit\src\main.rs:50)
minimal-winit.exe!winit::platform_impl::platform::event_loop::{{impl}}::run_return::{{closure}}<(),closure-0>(winit::platform_impl::platform::event_loop::{{impl}}::run_return::closure-0 * event, winit::event::Event<()> control_flow, winit::event_loop::ControlFlow *) Line 201 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:201)
minimal-winit.exe!alloc::boxed::{{impl}}::call_mut<(winit::event::Event<()>, mut winit::event_loop::ControlFlow*),FnMut<(winit::event::Event<()>, mut winit::event_loop::ControlFlow*)>>(core::ops::function::Box<FnMut<(winit::event::Event<()>, mut winit::event_loop::ControlFlow*)>> * self, winit::event::Event<()> args, winit::event_loop::ControlFlow *) Line 1023 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\liballoc\boxed.rs:1023)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::{{impl}}::call_event_handler::{{closure}}<()>(winit::platform_impl::platform::event_loop::runner::{{impl}}::call_event_handler::closure-0) Line 239 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:239)
minimal-winit.exe!std::panic::{{impl}}::call_once<(),closure-0>(std::panic::AssertUnwindSafe<closure-0> self) Line 319 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:319)
minimal-winit.exe!std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure-0>,()>(unsigned char * data) Line 307 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:307)
minimal-winit.exe!panic_unwind::__rust_maybe_catch_panic() Line 86 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libpanic_unwind\lib.rs:86)
minimal-winit.exe!std::panicking::try<(),std::panic::AssertUnwindSafe<closure-0>>(std::panic::AssertUnwindSafe<closure-0> f) Line 281 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:281)
minimal-winit.exe!std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure-0>,()>(std::panic::AssertUnwindSafe<closure-0> f) Line 394 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:394)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::catch_unwind<(),(),closure-0>(winit::platform_impl::platform::event_loop::runner::{{impl}}::call_event_handler::closure-0 self) Line 150 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:150)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::call_event_handler<()>(winit::event::Event<()> self) Line 247 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:247)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::send_event<()>(winit::event::Event<()> self) Line 208 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:208)
minimal-winit.exe!winit::platform_impl::platform::event_loop::SubclassInput<()>::send_event<()>(winit::event::Event<()> self) Line 90 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:90)
minimal-winit.exe!winit::platform_impl::platform::event_loop::public_window_callback::{{closure}}<()>(winit::platform_impl::platform::event_loop::public_window_callback::closure-0 *) Line 820 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:820)
minimal-winit.exe!core::ops::function::FnOnce::call_once<closure-0,()>(winit::platform_impl::platform::event_loop::public_window_callback::closure-0) Line 232 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libcore\ops\function.rs:232)
minimal-winit.exe!std::panic::{{impl}}::call_once<isize,closure-0>(std::panic::AssertUnwindSafe<closure-0> self) Line 318 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:318)
minimal-winit.exe!std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure-0>,isize>(unsigned char * data) Line 305 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:305)
minimal-winit.exe!panic_unwind::__rust_maybe_catch_panic() Line 86 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libpanic_unwind\lib.rs:86)
minimal-winit.exe!std::panicking::try<isize,std::panic::AssertUnwindSafe<closure-0>>(std::panic::AssertUnwindSafe<closure-0> f) Line 281 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:281)
minimal-winit.exe!std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure-0>,isize>(std::panic::AssertUnwindSafe<closure-0> f) Line 395 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:395)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::catch_unwind<(),isize,closure-0>(winit::platform_impl::platform::event_loop::public_window_callback::closure-0 self) Line 150 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:150)
minimal-winit.exe!winit::platform_impl::platform::event_loop::public_window_callback<()>(winapi::shared::windef::HWND__ * window, unsigned int msg, unsigned __int64 wparam, __int64 lparam, unsigned __int64, unsigned __int64 subclass_input_ptr) Line 1893 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:1893)
comctl32.dll!00007ffdae0eb762() (Unknown Source:0)
comctl32.dll!00007ffdae0eb625() (Unknown Source:0)
user32.dll!00007ffdb5f55c1d() (Unknown Source:0)
user32.dll!00007ffdb5f557ec() (Unknown Source:0)
user32.dll!00007ffdb5f61f83() (Unknown Source:0)
ntdll.dll!00007ffdb76bfde4() (Unknown Source:0)
win32u.dll!00007ffdb56a1764() (Unknown Source:0)
user32.dll!00007ffdb5f556fc() (Unknown Source:0)
minimal-winit.exe!winit::platform_impl::platform::event_loop::flush_paint_messages::{{closure}}<()>(winit::platform_impl::platform::event_loop::flush_paint_messages::closure-0 * redraw_window, winapi::shared::windef::HWND__ *) Line 682 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:682)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::owned_windows<(),closure-0>(winit::platform_impl::platform::event_loop::flush_paint_messages::closure-0 self) Line 188 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:188)
minimal-winit.exe!winit::platform_impl::platform::event_loop::flush_paint_messages<()>(core::option::Option<mut winapi::shared::windef::HWND__*> except, winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()> * runner) Line 683 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:683)
minimal-winit.exe!winit::platform_impl::platform::event_loop::thread_event_target_callback::{{closure}}<()>(winit::platform_impl::platform::event_loop::thread_event_target_callback::closure-0) Line 1938 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:1938)
minimal-winit.exe!std::panic::{{impl}}::call_once<isize,closure-0>(std::panic::AssertUnwindSafe<closure-0> self) Line 318 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:318)
minimal-winit.exe!std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure-0>,isize>(unsigned char * data) Line 305 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:305)
minimal-winit.exe!panic_unwind::__rust_maybe_catch_panic() Line 86 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libpanic_unwind\lib.rs:86)
minimal-winit.exe!std::panicking::try<isize,std::panic::AssertUnwindSafe<closure-0>>(std::panic::AssertUnwindSafe<closure-0> f) Line 281 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:281)
minimal-winit.exe!std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure-0>,isize>(std::panic::AssertUnwindSafe<closure-0> f) Line 395 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:395)
minimal-winit.exe!winit::platform_impl::platform::event_loop::runner::EventLoopRunner<()>::catch_unwind<(),isize,closure-0>(winit::platform_impl::platform::event_loop::thread_event_target_callback::closure-0 self) Line 150 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop\runner.rs:150)
minimal-winit.exe!winit::platform_impl::platform::event_loop::thread_event_target_callback<()>(winapi::shared::windef::HWND__ * window, unsigned int msg, unsigned __int64 wparam, __int64 lparam, unsigned __int64, unsigned __int64 subclass_input_ptr) Line 2120 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:2120)
comctl32.dll!00007ffdae0eb762() (Unknown Source:0)
comctl32.dll!00007ffdae0eb625() (Unknown Source:0)
user32.dll!00007ffdb5f55c1d() (Unknown Source:0)
user32.dll!00007ffdb5f557ec() (Unknown Source:0)
user32.dll!00007ffdb5f61f83() (Unknown Source:0)
ntdll.dll!00007ffdb76bfde4() (Unknown Source:0)
win32u.dll!00007ffdb56a1764() (Unknown Source:0)
user32.dll!00007ffdb5f556fc() (Unknown Source:0)
minimal-winit.exe!winit::platform_impl::platform::event_loop::EventLoop<()>::run_return<(),closure-0>(minimal_winit::main::closure-0 self) Line 217 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:217)
minimal-winit.exe!winit::platform_impl::platform::event_loop::EventLoop<()>::run<(),closure-0>(winit::platform_impl::platform::event_loop::EventLoop<()> self, minimal_winit::main::closure-0 event_handler) Line 185 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\platform_impl\windows\event_loop.rs:185)
minimal-winit.exe!winit::event_loop::EventLoop<()>::run<(),closure-0>(winit::event_loop::EventLoop<()> self, minimal_winit::main::closure-0 event_handler) Line 149 (c:\Users\drandreasdr\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.22.2\src\event_loop.rs:149)
minimal-winit.exe!minimal_winit::main() Line 46 (d:\Dropbox\Programming\rust\pixelsnew2\examples\minimal-winit\src\main.rs:46)
minimal-winit.exe!std::rt::lang_start::{{closure}}<core::result::Result<(), pixels::Error>>(std::rt::lang_start::closure-0 *) Line 67 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:67)
[Inline Frame] minimal-winit.exe!std::rt::lang_start_internal::{{closure}}() Line 52 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:52)
minimal-winit.exe!std::panicking::try::do_call<closure-0,i32>() Line 305 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:305)
minimal-winit.exe!panic_unwind::__rust_maybe_catch_panic() Line 86 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libpanic_unwind\lib.rs:86)
[Inline Frame] minimal-winit.exe!std::panicking::try() Line 281 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:281)
[Inline Frame] minimal-winit.exe!std::panic::catch_unwind() Line 394 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panic.rs:394)
minimal-winit.exe!std::rt::lang_start_internal() Line 51 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:51)
minimal-winit.exe!std::rt::lang_start<core::result::Result<(), pixels::Error>>(core::result::Result<(), pixels::Error>(*)() main, __int64 argc, unsigned char * * argv) Line 67 (d:\rustc\b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:67)
minimal-winit.exe!main() (Unknown Source:0)
[Inline Frame] minimal-winit.exe!invoke_main() Line 78 (d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
minimal-winit.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ffdb6677bd4() (Unknown Source:0)
ntdll.dll!00007ffdb768ce51() (Unknown Source:0)

Haven't heard back from OP in a few months, and this doesn't appear to be a bug in the crate. Closing for now. Feel free to comment if this should be reopened.

The shadow example creates one render pass for each light source and another for the forward rendering pass. A total of 3 render passes per frame. The water example also uses three render passes. This doesn't appear to align with the recommendations in the linked middleware article:

The goal of this api is to use a fewest possible render passes as possible. Reducing render passes is a very important for lower end hardware. These GPUs use a method called "tiled rendering" where there is significant cost to ending a render pass.

It may be that there is just no way to do these rendering techniques without multiple render passes. Which would extend to the pixels design with post processes render passes as separate render passes. And because the current render API does satisfy this design, I think think that optimizing it any more is necessary.

I will still keep this tracking ticket open, just in case things change in the future, or if new ideas happen to come up. Previous discussions suggested it may be nice to allow users to manage the GPU and treat pixels as just a piece of middleware. I no longer see that being the case with the render API accepting an arbitrary render pass (as described in the linked article) but I can still imagine a world where the application wants to own the wgpu resources (especially Device and Queue) but will allow pixels to borrow them. This I think is still on the table.

This ticket will track exploration to improve the render API further.

First up: Refactor the render API to follow the middleware pattern. This API replaces the CommandEncoder and TextureView references with a single RenderPass ref.

I'm not able to get this to work with closures, so the new API will force the caller to manage the swap chain, command encoder, and render pass. This design isn't in the spirit of pixels, which wants to minimize user responsibility over the GPU.

I also had trouble reusing the RenderPass for both pixels and the custom-shader example, as described by the Encapsulating Graphics Work article. The custom shader samples from a texture that is written by the pixels render pipeline. I have found a way to make this work with a single render pass, but some quick searching indicates that Vulkan has a concept of subpasses for this (and I cannot find any mention of this concept in webgpu).

Even if subpasses were implicit, the pixel that the fragment shader works on would need to be inout, which is apparently not valid at global scope. I wasn't even able to create a render pass with multiple color attachments (hoping the first pass would use the first attachment, the second pass uses the second attachment) but that didn't work because the render pipeline needs to know about all attachments! I must be missing something because deferred rendering doesn't appear to be possible at all.

@teevik I added an example that incorporates imgui. #116 Have a look and provide any feedback on that PR!

• Closes #90

For consistency, please use 2.0

colored = "2.0"

We can't use cargo-xbuild = "0.6" until we update the pinned version of rustc. See https://github.com/rust-osdev/cargo-xbuild/issues/88#issuecomment-669156940

The rustc version is specified in https://github.com/rust-console/cargo-n64/blob/f27f2ad58a1fcf78b734f99e8ae5e1918113a37e/rust-toolchain#L1 and also makes an appearance in https://github.com/rust-console/cargo-n64/blob/f27f2ad58a1fcf78b734f99e8ae5e1918113a37e/.travis.yml#L4 (but the version here is outdated)

Hi, thanks for writing this up.

The texture format can be set in the builder, so I don't think we would need to change the default. I'm also under the impression that Chrome will eventually support SRGB some day.

The wgpu authors are aware that the WASM target is currently broken. Some of that work was done in https://github.com/gfx-rs/wgpu-rs/pull/344 There is also the gekko branch, which is what they currently recommend for WASM targets. (Note this branch is closer to 0.5 than 0.6, so some of the API changes would have to be undone.) Here's the current documentation for building wgpu on WASM, if you are interested in taking this route.

Current status of WASM support in wgpu is "rough around the edges".

Expected Behavior

Signing into the Plex web app for the first time should walk you through the claim process and setup wizard.

Current Behavior

After signing in, I was left with a useless web client that didn't know it was server. It didn't matter how many times I tried to sign out and back in. I even removed all of my shared libraries in hopes that the UI was just messed up. That left me with the dreaded "Get Plex Media Server" button that everyone sees and no one knows what to actually do about.

To fix this, I had to:

1. Sign out of the web app
2. Add a password to my account through plex.tv (I have only used Google to sign in, up to this point)
3. Sign out of plex.tv
4. Run this script to claim the server

After that, signing in brought up the claim and setup wizard as expected.

Steps to Reproduce

1. Sign in for the first time after a fresh install (I used Google)
2. Notice that the web app shows all servers you already have shared, but not this new server. No option to claim it, either.
3. Search the web for 5 hours until you find the script linked above to fix it.
4. ???
5. Profit!

Environment

OS: LibreElec CPU architecture: arm64 How docker service was installed:

Installed through the normal LibreElec add-on repo.

The /data/movies volume is a CIFS mount, but that doesn't really matter. The files were all readable from within the container (docker exec -it plex bash and cat some files in /data/movies for fun...) and even an empty movies directory should not cause the Plex Media Server to be completely oblivious that it needs to be configured.

Command used to create docker container (run/create/compose/screenshot)

Just using the systemd unit that comes with the LibreElec addon. My CIFS mount is another systemd unit with a Before=docker.linuxserver.plex.service setting. Again, this shouldn't matter, since it only ensures files are visible to the container. And this was never a problem.

Docker logs

<details><summary>Click for boring useless logs</summary>

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-envfile: executing...
[cont-init.d] 01-envfile: exited 0.
[cont-init.d] 10-adduser: executing...
-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/
Brought to you by linuxserver.io
-------------------------------------
To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid:    65534
User gid:    65534
-------------------------------------
[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 40-chown-files: executing...
[cont-init.d] 40-chown-files: exited 0.
[cont-init.d] 45-plex-claim: executing...
[cont-init.d] 45-plex-claim: exited 0.
[cont-init.d] 50-gid-video: executing...
[cont-init.d] 50-gid-video: exited 0.
[cont-init.d] 60-plex-update: executing...
#####################################################
#   Login via the webui at http://<ip>:32400/web    #
#   and restart the docker, because there was no    #
#      plex token found in the preference file      #
#####################################################
[cont-init.d] 60-plex-update: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Starting Plex Media Server.

</details>

And FWIW, there is now a token in the preference file, but only after I ran the claim script that fixed everything. This was the old prefs file, pre-claim-script:

root@Plex-LibreELEC:/# cat '/config/Library/Application Support/Plex Media Server/Preferences.xml'
<?xml version="1.0" encoding="utf-8"?>
<Preferences OldestPreviousVersion="1.20.1.3252-a78fef9a9" MachineIdentifier="..." ProcessedMachineIdentifier="..." AnonymousMachineIdentifier="..." MetricsEpoch="1"/>

FWIW, the issue with this one is explained in detail in https://github.com/rust-windowing/winit/issues/219#issuecomment-315830359 and https://github.com/glfw/glfw/issues/1251