Pixi V8 Upgrade #1495
Pixi V8 Upgrade #1495
Conversation
Because Pixi init is async, we need to keep track of that promise, and delay many things until after it has settled.
|
Noting here the few issues that I'd like to check before merging this to main. None of this is really blocking.
|
Specifically, `deferredRedraw` is a thing the background tile layer will try to call.
We can use the max supported size to avoid the texture swaps. This works in WebGL, but seems to raise a warning in WebGPU. The WebGPU code is commented out for now.
This isn't a perfect solution, but it will prevent the Text Atlas from continuing to grow forever
A few things going on here: - We were calling `texSubImage2D` with the wrong rect (x,y,w,h) in some situations - It was using `texture.frame` which is the frame with the half pixel correction applied to it, making it 1px too small - this was introducing 1px of seam - In situations where we use padding (symbols and text), we need to remove the padding from the bin, so we can just use the bin as the rectangle for `texSubImage2D` - Also improved the calculations for the atlas sizes. Now we will prefer 8196x8196, but smaller sizes are fine too. Anything larger is just really unnecessary. - Tested tiles with and without the half-pixel correction, and yes we should still keep this code there to avoid textures from sampling neighbor texels.
This is a small improvement on 8afe728 WebGPU has a `writeTexture` call that works directly on ArrayBuffers, so we don't need to do an extra async copy with `createImageBitmap` to convert the pixels into an image supported by `copyExternalImageToTexture`.
This switches the DashLine plugin over to using textures instead of drawing every dash with geometry (moveTo/lineTo). This causes a huge speedup around places that have a lot of dashed lines, or very long dashed lines. Also simplified the DashLine internals, and fixed some various mysterious bugs in that code, and did the stuff needed to make it work on Pixi v8. I also renamed `DashLine.polygon` -> `DashLine.poly` to make it like pixi v8.
`&renderer=val` where val is one of `webgl1`, `webgl2` (or just `webgl`), `webgpu` Pixi will console log the renderer in use at startup.
|
Update on this... Pixi v8 offers a bunch of improvements - you can read more about them here. This also marks the first time that we can try out the new WebGPU renderer in Pixi. WebGPU is intended as the successor technology to WebGL. It's still an experimental technology in most web browsers, but it should prove to be even more performant in the future as browsers and Pixi improve their support for it. For now, WebGL remains the default renderer, and Rapid should continue to run on any device that supports even old versions of WebGL. 👉 We'd appreciate some help testing, so I added a url parameter to force Rapid to use a particular renderer:
If you have your browser developer console open, it will print the version of Pixi and which renderer is in use: If you do notice any issues when running Rapid with one of these flags, please report them here on GitHub, and let us know what you find! 🙇 |
bhousel
added
the
feature-renderer
Upgrade to Pixi v7 to v8 highlights several key changes that are expected to lead to significant performance improvements. These include:
Additionally, the description mentions that there are many other changes included in the update, which can be found in the here. Overall, the upgrade to Pixi v8 is expected to bring significant performance gains and improvements to the library.