wgpu msaa with svgs appears to crash

[m4b]

Iced appears to panic with mismatched pipeline when (I believe) svgs are used. MSAA works correctly for e.g., scroll boxes, rgba images, etc., but once svgs are loaded into the gui, the pipeline appears incompatible. Is this a supported usecase, or am I missing something?

[hecrj]

I tried enabling antialiasing in the svg example and everything works as expected.

MSAA is only used for Mesh primitives, which are only produced by the Canvas widget currently. svg should not interact with it in any way.

It would be great if you could share an SSCCE reproducing your issue.

[m4b]

So I get mismatched pipelines, e.g.:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `4`: The render pipeline and renderpass have mismatching sample_count', <::std::macros::panic macros>:5:6
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1063
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:470
  11: rust_begin_unwind
             at src/libstd/panicking.rs:378
  12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:332
  13: wgpu_core::command::render::<impl wgpu_core::hub::Global<G>>::command_encoder_run_render_pass
             at /home/m4b/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.5.0/<::std::macros::panic macros>:5
  14: wgpu_render_pass_end_pass
             at /home/m4b/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.5.0/src/command.rs:101
  15: <wgpu::RenderPass as core::ops::drop::Drop>::drop
             at /home/m4b/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.5.0/src/lib.rs:1542
  16: iced_wgpu::quad::Pipeline::draw
  17: iced_wgpu::renderer::Renderer::flush
  18: iced_wgpu::renderer::Renderer::draw
             at /home/m4b/.cargo/git/checkouts/iced-9e73d2fbe1fce35a/67b6f04/wgpu/src/renderer.rs:131

I basically do this:

        let mut encoder = self
            .device
            .create_command_encoder(&wgpu::CommandEncoderDescriptor {
                label: Some("RenderUi"),
            });
        let frame = self
            .window_data
            .swap_chain
            .get_next_texture().unwrap();
        let (attachment, resolve_target) = self.window_data.attachment(&frame);

        {
            let _rpass = encoder.begin_render_pass(&wgpu::RenderPassDescriptor {
                color_attachments: &[wgpu::RenderPassColorAttachmentDescriptor {
                    attachment,
                    resolve_target,
                    load_op: wgpu::LoadOp::Clear,
                    store_op: wgpu::StoreOp::Store,
                    clear_color: wgpu::Color {
                        r: 1.0,
                        g: 0.0,
                        b: 0.0,
                        a: 1.0,
                    },
                }],
                depth_stencil_attachment: None,
            });
        }

        self.iced.render(
            &mut self.device,
            &mut encoder,
            &attachment,
            self.window_data.window_dimensions,
            &self.window,
        );

where attachment is the msaa framebuffer, and resolve_target is the frame.view

[m4b]

This is on commit 67b6f044e870df41be9; if i pass frame.view (e.g., the SwapchainOutput, it runs without error...)

[hecrj]

@m4b MSAA is handled and resolved internally by the renderer. The render target should always have a sample_count of 1.

[m4b]

oh i see, for some reason i assumed i would be in control of msaa + target, and iced would render into same render pass, but maybe that's infeasible (but as api is now, i should have seen it must have its own msaa texture and wants to render into target i give it). Might be nice to also allow user to send in the msaa buffer + target so same render pass is used (not sure if thats feasible)?

[discordance]

Having a similar issue here, might be related as we use SVGs too, with the following config:

iced_settings.antialiasing = Some(Antialiasing::MSAAx4);

MacOS 10.13

Edit: we use an outdated wgpu version so this might be fixed already.

[discordance]

tried with wgpu 0.12 on MacOS 10.13, same issue. It works without MSAA

[hecrj]

SSCCE needed here. Closing for now.