Only allow 2d textures for copyImageBitmapToTexture for now - #1335
Conversation
It's more minimal and solves the majority of usecases. We can generalize it anytime.
|
We could even consider limiting it to 2d textures with a depth (layer count) of 1. |
|
I think we want to keep support for 2D array textures so applications can load their texture arrays (like cubemaps used for lightprobes or other stuff) using that method. |
|
Happy to add a restriction, but what's the reasoning behind it? |
Just to reduce unnecessary scope creep for the sake of generality. |
|
@kainino0x Glad to have this. |
|
Resolution: accepted |
|
We actually do want this for 1d and 3d textures, so we'll need to add this back. |
|
I'm not sure how useful it is for 1d textures. They're kind of a niche feature that I think mostly gets used for pre-computed lookup tables (not downloaded resources). I kind of agree for 3D but I'm not exactly sure how perf sensitive it is - and the cpu path always still exists. Also note that uploading into 3d (or 2d array) textures from a 2d source requires multiple calls because we can't (currently) express tiled 2d-to-3d copies like WebGL. |
This commit changes execution of a testcase such that await'ing of all subcases is await'ed at the end of a testcase. This allows better test throughput by allowing subsequent subcases to begin without waiting on previous eventual expectations. Because eventual expectations now record logs for a subcase asynchronously after other subcases may have started running, subcase logs are recorded in a deferred manner through a Proxy. This allows logs to appear as if subcases were executed serially.
It's more minimal and solves the majority of usecases. We can generalize it anytime.
Preview | Diff