[Windows] Move to FlutterCompositor for rendering

[loic-sharma]

This migrates the Windows embedder to FlutterCompositor so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.

Tests...

• Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
• Software compositor's raster time and memory isn't regressed

Test device configurations

• Windows 11 (hardware acceleration enabled/disabled)
• Windows Arm64 (hardware acceleration enabled/disabled)
• Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)

Addresses flutter/flutter#128904

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[loic-sharma]

The CompositorOpenGL mirrors Linux's backing store provider:

engine/shell/platform/linux/fl_backing_store_provider.cc

Lines 19 to 102 in 101396f

	static void fl_backing_store_provider_dispose(GObject* object) {
	FlBackingStoreProvider* self = FL_BACKING_STORE_PROVIDER(object);
	glDeleteFramebuffers(1, &self->framebuffer_id);
	glDeleteTextures(1, &self->texture_id);
	G_OBJECT_CLASS(fl_backing_store_provider_parent_class)->dispose(object);
	}
	static void fl_backing_store_provider_class_init(
	FlBackingStoreProviderClass* klass) {
	G_OBJECT_CLASS(klass)->dispose = fl_backing_store_provider_dispose;
	}
	static void fl_backing_store_provider_init(FlBackingStoreProvider* self) {}
	FlBackingStoreProvider* fl_backing_store_provider_new(int width, int height) {
	FlBackingStoreProvider* provider = FL_BACKING_STORE_PROVIDER(
	g_object_new(fl_backing_store_provider_get_type(), nullptr));
	provider->geometry = {
	.x = 0,
	.y = 0,
	.width = width,
	.height = height,
	};
	glGenTextures(1, &provider->texture_id);
	glGenFramebuffers(1, &provider->framebuffer_id);
	glBindFramebuffer(GL_FRAMEBUFFER, provider->framebuffer_id);
	glBindTexture(GL_TEXTURE_2D, provider->texture_id);
	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
	glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, width, height, 0, GL_RGBA,
	GL_UNSIGNED_BYTE, NULL);
	glBindTexture(GL_TEXTURE_2D, 0);
	glFramebufferTexture2D(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
	GL_TEXTURE_2D, provider->texture_id, 0);
	return provider;
	}
	uint32_t fl_backing_store_provider_get_gl_framebuffer_id(
	FlBackingStoreProvider* self) {
	return self->framebuffer_id;
	}
	uint32_t fl_backing_store_provider_get_gl_texture_id(
	FlBackingStoreProvider* self) {
	return self->texture_id;
	}
	uint32_t fl_backing_store_provider_get_gl_target(FlBackingStoreProvider* self) {
	return GL_TEXTURE_2D;
	}
	uint32_t fl_backing_store_provider_get_gl_format(FlBackingStoreProvider* self) {
	// Flutter defines SK_R32_SHIFT=16, so SK_PMCOLOR_BYTE_ORDER should be BGRA.
	// In Linux kN32_SkColorType is assumed to be kBGRA_8888_SkColorType.
	// So we must choose a valid gl format to be compatible with surface format
	// BGRA8.
	// Following logics are copied from Skia GrGLCaps.cpp.
	if (epoxy_is_desktop_gl()) {
	// For OpenGL.
	if (epoxy_gl_version() >= 12 || epoxy_has_gl_extension("GL_EXT_bgra")) {
	return GL_RGBA8;
	}
	} else {
	// For OpenGL ES.
	if (epoxy_has_gl_extension("GL_EXT_texture_format_BGRA8888") ||
	(epoxy_has_gl_extension("GL_APPLE_texture_format_BGRA8888") &&
	epoxy_gl_version() >= 30)) {
	return GL_BGRA8_EXT;
	}
	}
	g_critical("Failed to determine valid GL format for Flutter rendering");
	return GL_RGBA8;
	}

[loic-sharma]

The Windows embedder uses Impeller's ProcTableGLES and DescriptionGLES to resolve OpenGLES functions and determine the GL version and extensions. This was the approach recommended by Impeller folks: https://discord.com/channels/608014603317936148/1173336353187041380/1182110838849536040

Also note that Windows has a GlProcTable which is a worse version of Impeller's ProcTableGLES. I was hoping to converge everything to ProcTableGLES, however, ProcTableGLES's initialization requires that the GL context is current. This prevents us from using ProcTableGLES on the platform thread as it ideally shouldn't make the context current. We'll want to clean this up somehow in the future...

[jonahwilliams]

why does impeller require the context to be current - do we combine creation of the proc table with looking up gl state? Could we split that functionality out of proc table so you could use it exclusively?

[loic-sharma]

do we combine creation of the proc table with looking up gl state?

Yes. The proc table uses the DescriptionGLES to determine capabilities and determine supported extension functions, and the DescriptionGLES constructor fails if the context isn't current.

Could we split that functionality out of proc table so you could use it exclusively?

I think so. We could have a "raw" proc table that can be initialized without a GL context, does not have the description/capabilities, and includes potentially unsupported extension functions. The "safe" proc table would load the description/capabilities and remove unsupported functions. This might require a little experimentation to get the API right.

[yaakovschectman]

LGTM as long as we're going with the C stdlib memory management

[yaakovschectman]

This reminds me:
This wouldn't be in this PR, but how about iterating through however many backing store layers there are and blending them per-pixel-alpha so we can composite an arbitrary number of layers? I'm doing something similar on my local branch working with platform views. If that sounds good, I can start a PR once this lands to add that here.

[loic-sharma]

That sounds reasonable but before that PR we'd first want a design doc shared and reviewed by everyone :)

[cbracken]

Overall looks great -- just a few nits!

[jonahwilliams]

Usage looks fine to me. But if we can make an adjustment to proc table to make it more useful we should do that.

[loic-sharma]

Reverting. The framework tree became red on Windows run_debug_test_windows and Windows_arm64 run_debug_test_windows once this commit rolled to the framework.

Example failure: https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20run_debug_test_windows/5826/overview

[wanjm]

why it is reverted?