WebXR Layers: Avoid openxr failure due to too many layers [chromium/src : main]
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 1 comment![]( "Open in Gerrit")
Alex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Related details
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brandon Jones (Gerrit)
Brandon Jones added 1 comment![]( "Open in Gerrit")
Alex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
I don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Related details
- Alexander Cooper
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
I don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Yeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Yeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
A tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
Related details
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
A tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
I thought we were able to create that in a single texture. Or did you mean Cube?
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
Alexander CooperA tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
I thought we were able to create that in a single texture. Or did you mean Cube?
No, cube will only use one openxr layer. We do use a single texture, but for each eye, we create an XrCompositionLayerQuad with different sub image rects, so we end up with 2 XrCompoositionLayerQuad objects.
Related details
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
Alexander CooperA tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
Yong Li (xWF)I thought we were able to create that in a single texture. Or did you mean Cube?
No, cube will only use one openxr layer. We do use a single texture, but for each eye, we create an XrCompositionLayerQuad with different sub image rects, so we end up with 2 XrCompoositionLayerQuad objects.
Sorry, I'm not following why Quad is unique for this then?
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
Alexander CooperA tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
Yong Li (xWF)I thought we were able to create that in a single texture. Or did you mean Cube?
Alexander CooperNo, cube will only use one openxr layer. We do use a single texture, but for each eye, we create an XrCompositionLayerQuad with different sub image rects, so we end up with 2 XrCompoositionLayerQuad objects.
Sorry, I'm not following why Quad is unique for this then?
Sorry for confusing. I used quad layer just as an example. Cylinder and equirect have same issue.
Related details
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
Brandon JonesAlex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
Alexander CooperA tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
Yong Li (xWF)I thought we were able to create that in a single texture. Or did you mean Cube?
Alexander CooperNo, cube will only use one openxr layer. We do use a single texture, but for each eye, we create an XrCompositionLayerQuad with different sub image rects, so we end up with 2 XrCompoositionLayerQuad objects.
Yong Li (xWF)Sorry, I'm not following why Quad is unique for this then?
Sorry for confusing. I used quad layer just as an example. Cylinder and equirect have same issue.
Chatted with Brandon; modification is we'll call it a "maxLayerRenderCost" (or "maxLayerBudget") as the attribute on the XRSession and modify each of the layers to expose a "renderCost" attribute. The stereo objects can report 2 and mono/projection layers can report 1.
Essentially, I don't want to surprise developers that e.g. one of their layers (or worse one of the eyes for one of their layers) doesn't render.
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Okay, spoke with the working group, and I'll update the github. For now the preference is to expose only `maxRenderLayers` on XRSession, and just cut that number in half (and actually I think we want half-1 because we want to reserve an overlay layer for ourselves for future usage). It likely often leaves more headroom than we need; but it seems to be adequate for most developers needs.
Yong Li (xWF) (Gerrit)
Message from Yong Li (xWF)![]( "Open in Gerrit")
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper voted and added 9 comments![]( "Open in Gerrit")
Votes added by Alexander Cooper
| Code-Review | +1 |
9 comments
DCHECK_LE(layers->PrimaryLayerCount(), max_layer_count_);CHECK_LE is fine I think; but we should also try to do a `mojo::ReportBadMessage` style validation on the end of the pipe that ends up setting the layers (and thus layers->PrimaryLayerCount).
if (!max_layer_count_) {Prefer explicit `max_layer_count_ == 0` check.
// Just in case.NIT: Unnecessary comment.
// A quad, equirect or cylinder layer may need 2 XrCompositionLayer objects
// for both eyes. We may also show the base layer.Non-Nit: Change the comment about "We may show the base layer" to indicate that we actually just reserve one layer for our own use. Right now it's the base layer, but long term I'd like to change how that works.
NIT (and also checking my understanding), consider re-wording (with incorporating above non-nit as well) to something like:
"Except for the projection layer, stereo layers actually need 2 XrCompositionLayer objects (one per eye). For now, divide the amount of available layers by 2 to avoid blink trying to activate too many layers at once. Further, we reserve one layer for our own use."
"The number of layers to be enabled exists maxRenderLayers.";exceeds
```suggestion
"The number of layers to be enabled exceeds maxRenderLayers.";
```
exception_state.ThrowTypeError(kTooManyLayers);I was probably going to put it in the spec as `NotSupportedError`., and we should do the check before this for loop.
readonly attribute unsigned short maxRenderLayers;Add `[RuntimeEnabled=WebXRLayers]` here, and keep it out of virtual/stable/webexposed until we enable the feature.
getter maxRenderLayersAdding the runtime enabled attribute will make you need to revert this change.
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 9 comments![]( "Open in Gerrit")
Alex, I am not sure it is good to fail create*Layer() or updateRenderState() just because there are too many layers. Especially during the test, I found the base layer may occasionally be required but then be removed (must be due to overlay). Also, a quad layer with stereo-* layout will be counted as 2 layers. So I end up the current solution which just ignore some layers when the number exceeds the limit, so openxr can still be happy.
Alexander CooperI don't think we should fail create___Layer() because the developer may not be using every layer they create simultaneously. updateRenderState() would be a more appropriate choice to surface an error at, as it matches the behavior of OpenXR more closely.
Alexander CooperYeah, the spec *does* allow limiting the number of created layers; but I think Brandon is right that that number probably shouldn't be exactly the number that is set. I *do* think we should plumb the "max set" layers up to blink and reject in updateRenderState though, and then add a `reportBadMessage` call here if the layers size is larger than what we said the max could/should be.
Let's call it a `NotSupportedError`, and I'll draft a spec issue/spec text for it. I think it should be fairly non-controversial.
Yong Li (xWF)
Alexander CooperA tricky thing is one quad layer with stereo-left-right layout will be counted as 2 layers by openxr because we create 2 layers respectively for 2 eyes.
Yong Li (xWF)I thought we were able to create that in a single texture. Or did you mean Cube?
Alexander CooperNo, cube will only use one openxr layer. We do use a single texture, but for each eye, we create an XrCompositionLayerQuad with different sub image rects, so we end up with 2 XrCompoositionLayerQuad objects.
Yong Li (xWF)Sorry, I'm not following why Quad is unique for this then?
Alexander CooperSorry for confusing. I used quad layer just as an example. Cylinder and equirect have same issue.
Alexander CooperChatted with Brandon; modification is we'll call it a "maxLayerRenderCost" (or "maxLayerBudget") as the attribute on the XRSession and modify each of the layers to expose a "renderCost" attribute. The stereo objects can report 2 and mono/projection layers can report 1.
Essentially, I don't want to surprise developers that e.g. one of their layers (or worse one of the eyes for one of their layers) doesn't render.
Okay, spoke with the working group, and I'll update the github. For now the preference is to expose only `maxRenderLayers` on XRSession, and just cut that number in half (and actually I think we want half-1 because we want to reserve an overlay layer for ourselves for future usage). It likely often leaves more headroom than we need; but it seems to be adequate for most developers needs.
Acknowledged
DCHECK_LE(layers->PrimaryLayerCount(), max_layer_count_);CHECK_LE is fine I think; but we should also try to do a `mojo::ReportBadMessage` style validation on the end of the pipe that ends up setting the layers (and thus layers->PrimaryLayerCount).
Added a check in SetEnabledCompositionLayers.
Prefer explicit `max_layer_count_ == 0` check.
Done
// Just in case.Yong Li (xWF)NIT: Unnecessary comment.
Done
// A quad, equirect or cylinder layer may need 2 XrCompositionLayer objects
// for both eyes. We may also show the base layer.Non-Nit: Change the comment about "We may show the base layer" to indicate that we actually just reserve one layer for our own use. Right now it's the base layer, but long term I'd like to change how that works.
NIT (and also checking my understanding), consider re-wording (with incorporating above non-nit as well) to something like:
"Except for the projection layer, stereo layers actually need 2 XrCompositionLayer objects (one per eye). For now, divide the amount of available layers by 2 to avoid blink trying to activate too many layers at once. Further, we reserve one layer for our own use."
Done
"The number of layers to be enabled exists maxRenderLayers.";exceeds
```suggestion
"The number of layers to be enabled exceeds maxRenderLayers.";
```
Done
I was probably going to put it in the spec as `NotSupportedError`., and we should do the check before this for loop.
Done
Add `[RuntimeEnabled=WebXRLayers]` here, and keep it out of virtual/stable/webexposed until we enable the feature.
Done
Adding the runtime enabled attribute will make you need to revert this change.
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper voted and added 2 comments![]( "Open in Gerrit")
Votes added by Alexander Cooper
| Code-Review | +1 |
2 comments
DCHECK_LE(layers->PrimaryLayerCount(), max_layer_count_);Yong Li (xWF)CHECK_LE is fine I think; but we should also try to do a `mojo::ReportBadMessage` style validation on the end of the pipe that ends up setting the layers (and thus layers->PrimaryLayerCount).
Added a check in SetEnabledCompositionLayers.
Sorry, can you switch this from `DCHECK_LE` to `CHECK_LE`
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper added 1 comment![]( "Open in Gerrit")
getter maxRenderLayersThe problem with the test failures is that *this* one (note how it's just under web_tests/webexposed and *not* web_tests/virtual/stable/webexposed) *is* needed.
Yong Li (xWF) (Gerrit)
Yong Li (xWF) added 2 comments![]( "Open in Gerrit")
DCHECK_LE(layers->PrimaryLayerCount(), max_layer_count_);Yong Li (xWF)CHECK_LE is fine I think; but we should also try to do a `mojo::ReportBadMessage` style validation on the end of the pipe that ends up setting the layers (and thus layers->PrimaryLayerCount).
Alexander CooperAdded a check in SetEnabledCompositionLayers.
Sorry, can you switch this from `DCHECK_LE` to `CHECK_LE`
Done
getter maxRenderLayersThe problem with the test failures is that *this* one (note how it's just under web_tests/webexposed and *not* web_tests/virtual/stable/webexposed) *is* needed.
- Alexander Cooper
- Brandon Jones
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper voted Code-Review+1![]( "Open in Gerrit")
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brandon Jones (Gerrit)
Brandon Jones voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gwsq (Gerrit)
Message from gwsq![]( "Open in Gerrit")
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: ke...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
IPC reviewer(s): ke...@chromium.org
Reviewer source(s):
ke...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
Related details
- Ken Buchanan
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Ken Buchanan (Gerrit)
Ken Buchanan voted and added 1 comment![]( "Open in Gerrit")
Votes added by Ken Buchanan
| Code-Review | +1 |
1 comment
Related details
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Blink W3C Test Autoroller (Gerrit)
Message from Blink W3C Test Autoroller![]( "Open in Gerrit")
Exportable changes to web-platform-tests were detected in this CL and a pull request in the upstream repo has been made: https://github.com/web-platform-tests/wpt/pull/57293.
When this CL lands, the bot will automatically merge the PR on GitHub if the required GitHub checks pass; otherwise, ecosystem-infra@ team will triage the failures and may contact you.
WPT Export docs:
https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#Automatic-export-process
Related details
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yong Li (xWF) (Gerrit)
Ken Buchanan (Gerrit)
Ken Buchanan voted Code-Review+1![]( "Open in Gerrit")
- Alexander Cooper
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Alexander Cooper (Gerrit)
Alexander Cooper voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Brandon Jones
- Yong Li (xWF)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yong Li (xWF) (Gerrit)
Yong Li (xWF) voted Commit-Queue+2![]( "Open in Gerrit")
| Commit-Queue | +2 |
Related details
- Brandon Jones
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
WebXR Layers: Avoid openxr failure due to too many layers
- Add maxRenderLayers to XrSession.
- Apply a safe guard when passing layers to OpenXR.
- Also add a trace for number of layers passed to OpenXR.
- M device/vr/openxr/openxr_api_wrapper.cc
- M device/vr/openxr/openxr_api_wrapper.h
- M device/vr/openxr/openxr_render_loop.cc
- M device/vr/openxr/test/fake_openxr_impl_api.cc
- M device/vr/public/mojom/vr_service.mojom
- M third_party/blink/renderer/modules/xr/xr_session.cc
- M third_party/blink/renderer/modules/xr/xr_session.h
- M third_party/blink/renderer/modules/xr/xr_session.idl
- M third_party/blink/web_tests/external/wpt/resources/chromium/webxr-test.js
- M third_party/blink/web_tests/webexposed/global-interface-listing-expected.txt
Code-Review: +1 by Ken Buchanan, +1 by Alexander Cooper
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
luci-bisection@appspot.gserviceaccount.com (Gerrit)
luci-bi...@appspot.gserviceaccount.com has created a revert of this change![]( "Open in Gerrit")
Related details
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |