https://oskarstalberg.com/Townscaper/ is slower than it should be
Seems to spend most of its time in initialising blited-to textures: Sample Count, Samples %, Normalized CPU %, Symbol 4981, 17.7%, 3.1%, WebCore::jsWebGL2RenderingContextPrototypeFunction_blitFramebuffer(JSC::JSGlobalObject*, JSC::CallFrame*) (in WebCore) 4981, 17.7%, 3.1%, WebCore::GraphicsContextGLOpenGL::blitFramebuffer(int, int, int, int, int, int, int, int, unsigned int, unsigned int) (in WebCore) 4981, 17.7%, 3.1%, gl::BlitFramebuffer(int, int, int, int, int, int, int, int, unsigned int, unsigned int) (in libANGLE-shared.dylib) 4981, 17.7%, 3.1%, gl::Context::blitFramebuffer(int, int, int, int, int, int, int, int, unsigned int, unsigned int) (in libANGLE-shared.dylib) 4981, 17.7%, 3.1%, gl::Context::syncState(angle::IterableBitSet<63ul> const&, angle::BitSetT<12ul, unsigned int, unsigned long> const&, gl::Command) (in libANGLE-shared.dylib) 4952, 17.6%, 3.1%, gl::Framebuffer::ensureDrawAttachmentsInitialized(gl::Context const*) (in libANGLE-shared.dylib) 4952, 17.6%, 3.1%, gl::(anonymous namespace)::InitAttachment(gl::Context const*, gl::FramebufferAttachment*) (in libANGLE-shared.dylib) 4952, 17.6%, 3.1%, gl::FramebufferAttachment::initializeContents(gl::Context const*) (in libANGLE-shared.dylib) 4952, 17.6%, 3.1%, rx::TextureMtl::initializeContents(gl::Context const*, gl::ImageIndex const&) (in libANGLE-shared.dylib) 4930, 17.5%, 3.0%, rx::mtl::InitializeTextureContents(gl::Context const*, std::__1::shared_ptr<rx::mtl::Texture> const&, rx::mtl::Format const&, rx::mtl::ImageNativeIndex const&) (in libANGLE-shared.dylib) 4921, 17.5%, 3.0%, rx::mtl::Texture::replaceRegion(rx::ContextMtl*, MTLRegion const&, gl::LevelIndexWrapper<unsigned int> const&, unsigned int, unsigned char const*, unsigned long, unsigned long) (in libANGLE-shared.dylib)
Wonder whether this may have already been addressed upstream in ANGLE. Let's let the mega ANGLE upgrade in Bug 220896 land and see whether this still reproduces. If it hasn't been, let's definitely skip initialization when overwriting the complete destination texture. Will that address this issue?
<rdar://problem/86328437>