Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken text rendering on wasm32 target in Firefox #78

Open
pacmancoder opened this issue Oct 23, 2021 · 5 comments
Open

Broken text rendering on wasm32 target in Firefox #78

pacmancoder opened this issue Oct 23, 2021 · 5 comments
Labels
bug Something isn't working
Milestone

Comments

@pacmancoder
Copy link

pacmancoder commented Oct 23, 2021

I have managed to compile hello example to wasm32 target with some changes to winit initialization, however, when trying to render new text on the next frame, part of the text disappear (e.g I just render text with content that changes each frame with format!("Frame {}!, counter)).

I have modified the example I'm my fork to help reproduce the issue:
https://github.com/pacmancoder/wgpu_glyph/tree/issue-report/wasm32-text-rendering

UPD: Reproduces only on Firefox (v93)

Steps to run example on wasm32

# 0. Install prerequisites
cargo install wasm-bindgen-cli https
# 1. Compile wasm module
cargo build --example hello --target=wasm32-unknown-unknown
# 2. Invoke wasm-bindgen
wasm-bindgen target/wasm32-unknown-unknown/debug/examples/hello.wasm --out-dir . --target web --no-typescript
# 3. run http server
http
# 4. Open 127.0.0.1:8000 in browser

Results can be compared with non-wasm32 build of example cargo run --example hello

Normal behavior; Compiled for non-wasm32 target

image

Text artifacts of wasm32 target, part of the text is missing

image

Not sure yet if it is related to wgpu or wgpu_glyph implementation.

@pacmancoder
Copy link
Author

UPD: Huh... Looks like it reproduces only on Firefox (v93)....

@pacmancoder
Copy link
Author

pacmancoder commented Oct 23, 2021

When wgpu is updated to thje latest master (gfx-rs/wgpu@d46c39a) It produces even more bizarre results (still, only on Firefox)

image

UPD1: Decreasing initial cache cache makes this bug even funnier (yep, still reproduces only in Firefox):

WARNING: Quickli changing images (gif)

bug

UPD2: Set draw_cache_align_4x4(true) (I missed the fact that is should be enabled on WebGL), but still, no visible change.

@pacmancoder pacmancoder changed the title Broken text rendering on wasm32 target Broken text rendering on wasm32 target in Firefox Oct 23, 2021
@hecrj hecrj added the bug Something isn't working label Oct 25, 2021
@hecrj
Copy link
Owner

hecrj commented Oct 25, 2021

  • Are we sure the example is leveraging WebGL and not the experimental WebGPU API?
  • The example in your fork does not match the screenshots you shared. There is no "Frame #" text in the source.
  • If I had to guess, I'd say that there is something up with the cache upload logic here:
    // It is a webgpu requirement that:
    // BufferCopyView.layout.bytes_per_row % wgpu::COPY_BYTES_PER_ROW_ALIGNMENT == 0
    // So we calculate padded_width by rounding width
    // up to the next multiple of wgpu::COPY_BYTES_PER_ROW_ALIGNMENT.
    let align = wgpu::COPY_BYTES_PER_ROW_ALIGNMENT as usize;
    let padded_width_padding = (align - width % align) % align;
    let padded_width = width + padded_width_padding;
    let padded_data_size = (padded_width * height) as u64;
    if self.upload_buffer_size < padded_data_size {
    self.upload_buffer =
    device.create_buffer(&wgpu::BufferDescriptor {
    label: Some("wgpu_glyph::Cache upload buffer"),
    size: padded_data_size,
    usage: wgpu::BufferUsages::COPY_DST
    | wgpu::BufferUsages::COPY_SRC,
    mapped_at_creation: false,
    });
    self.upload_buffer_size = padded_data_size;
    }
    let mut padded_data = staging_belt.write_buffer(
    encoder,
    &self.upload_buffer,
    0,
    NonZeroU64::new(padded_data_size).unwrap(),
    device,
    );
    for row in 0..height {
    padded_data[row * padded_width..row * padded_width + width]
    .copy_from_slice(&data[row * width..(row + 1) * width])
    }
    // TODO: Move to use Queue for less buffer usage
    encoder.copy_buffer_to_texture(
    wgpu::ImageCopyBuffer {
    buffer: &self.upload_buffer,
    layout: wgpu::ImageDataLayout {
    offset: 0,
    bytes_per_row: NonZeroU32::new(padded_width as u32),
    rows_per_image: NonZeroU32::new(height as u32),
    },
    },
    wgpu::ImageCopyTexture {
    texture: &self.texture,
    mip_level: 0,
    origin: wgpu::Origin3d {
    x: u32::from(offset[0]),
    y: u32::from(offset[1]),
    z: 0,
    },
    aspect: wgpu::TextureAspect::All,
    },
    wgpu::Extent3d {
    width: size[0] as u32,
    height: size[1] as u32,
    depth_or_array_layers: 1,
    },
    );

@hecrj hecrj modified the milestones: 0.15.1, 0.15.2 Oct 25, 2021
pacmancoder added a commit to pacmancoder/wgpu_glyph that referenced this issue Oct 25, 2021
@pacmancoder
Copy link
Author

pacmancoder commented Oct 25, 2021

@hecrj Wow, I forgot to push local changes to the fork 🥴... Now it is in place, sorry for that!

Well, I explicitly ask wgpu for wgpu::Backends::GL backend, so unless if something is completely broken in wgpu, it should use WebGL, I guess...

Yea, my bet is too on the broken caching logic, but I not yet figured out what shat is specifically wrong with it...

@Tnze
Copy link

Tnze commented Mar 15, 2022

Similar problems were encountered when i was using iced v0.3.0. the last few words are not rendered.

not the web but default wgpu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants