| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Thanks!
std::move(dispatcher_task_runner),musing for potential followup: is it a bit odd for the placeholder to have these ties to the dispatcher now (here and just below)?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
musing for potential followup: is it a bit odd for the placeholder to have these ties to the dispatcher now (here and just below)?
So there are two separate things:
I see two options to clarify this:
Orthogonal to this we should move [this](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/canvas_resource_dispatcher.cc;drc=1adcb18ff079091fcb79278f0941ac5bc9227752;l=260) out of CRD.
I'll take a look once this settles down.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
2 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Move placeholder_client out of the CanvasResourceDispatcher
It's really part of the OffscreenCanvas itself, so move it there. No
functional changes, the life time matches CRD.
In a follow-up we should just create it once when we become thread
bound.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thanks!
std::move(dispatcher_task_runner),Vasiliy Telezhnikovmusing for potential followup: is it a bit odd for the placeholder to have these ties to the dispatcher now (here and just below)?
So there are two separate things:
- Task runner, which is just "this thread task runner". I plan to move creation of the placeholder client to GetContext (it's where we become thread bound and canvas can't be moved across threads anymore), then we'd just use `GetTaskRunner(TaskType::kInternalDefault);`
- Animation state. This is a bit tricky, maybe we should change logic a bit for clarity. Essentially it's placeholder canvas forwards [page visibility signal](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/canvas/html_canvas_element.cc;drc=5971f5f9d8aa5434519791361e63cdac46520baa;l=1742). This information really belongs to placeholder<=>canvas communication, but it does affect how CRD needs to work (should it request BeginFrame from viz or should it run timer, because viz won't send anything), so we need to tell dispatcher something.
I see two options to clarify this:
- Send visibility/presence of capture from placeholder, compute animation state here. It would require sending two fields instead of one (and so we'd need to store [deferred value](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/offscreen_canvas_placeholder.cc;drc=ea1f27a398caf47ad1459dc6c10d65871c947721;l=81).
- Instead of having lambda here, have a real function, so it's a bit more obvious what we're doing.
Orthogonal to this we should move [this](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/graphics/canvas_resource_dispatcher.cc;drc=1adcb18ff079091fcb79278f0941ac5bc9227752;l=260) out of CRD.
I'll take a look once this settles down.
SGTM, thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |