net: Image Cache: Spawn setting image keys on thread pool - #44483
Conversation
|
🔨 Triggering try run (#24892134692) for Linux (WPT) |
|
Test results for linux-wpt from try job (#24892134692): Flaky unexpected result (39)
Stable unexpected results that are known to be intermittent (18)
|
|
✨ Try run (#24892134692) succeeded. |
|
Hrm. If the problem is loading the image, won't this only affect things when images have been waiting for keys? Why not selectively load large images on a separate thread when we detect that they are large enough to warrant this? |
|
Currently all images (except the first will be waiting for keys, so it should catch almost all. The advantage of doing it like this is that ImageCacheStore is in a Arc<Mutex<_>> and currently it is very nice to reason about it because everything inside does not have inner mutability. The alternative would be to spawn thread for |
|
@mrobinson any update on this? |
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
f85dd47 to
733b39a
Compare
|
Here's an alternative proposal:
The thread pool tasks are only responsible for calling set_key_and_finish_load with the provided data. Some callers of load_image_with_keycache already exist in spawned tasks so we can add a flag to force a synchronous operation for those cases. |
|
I am not sure if I will have time to work on it but I don't quite understand some points you made.
|
jdm
left a comment
There was a problem hiding this comment.
Ok, I needed some time to convince myself that we weren't overlooking the case where we already have cached keys. In that case we already spawn a task on the thread pool to perform the image decoding and then set the webrender key. With the changes in this PR we just need to ensure that new batches of image keys trigger the same off-thread webrender key creation. This looks like a reasonable way to make that happen.
This replaces the
fill_key_cache_with_batch_of_keyswithdispatch_fill_key_cache_with_batch_of_keysto put it on the already existing thread pool.fill_key_cache_with_batch_of_keysis called from the ScriptThread and callsset_webrender_image_keywhich creates an IpcSharedMemory. For large images this can take a long time.Offloading it away from the ScriptThread means it has more time for important work.
We additionally add some safeguards around ImageCache to prevent us from requesting new ImageKeys while we are processing them.
Testing: WPT tests will probably not find this implementation issue as it is mostly equivalent code except in the case of data races.