Broken text rendering on wasm32 target in Firefox

[pacmancoder]

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

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

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

[pacmancoder]

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

[pacmancoder]

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

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

WARNING: Quickli changing images (gif)

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

[hecrj]

• 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:
  

  wgpu_glyph/src/pipeline/cache.rs

  Lines 60 to 121 in cd6f154

  	// 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,
  	},
  	);

[pacmancoder]

@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]

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