[Webkit-unassigned] [Bug 178020] New: Resource loaded data buffering should be controlled by only one strategy for WK1 and WK2

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=178020

            Bug ID: 178020
           Summary: Resource loaded data buffering should be controlled by
                    only one strategy for WK1 and WK2
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com

This bug is filed to address youenn fablet's comments in https://bugs.webkit.org/show_bug.cgi?id=175890. Currently the state of the image buffering is the following:

WK2: The buffering happens in the network process only if the image is a sub-resource. I think this buffering was added to avoid sending too many IPC calls for a large resource like the image.
WK1: No image buffering is done because the WK1 is a single process and no IPC calls are involved.
iOS: BitmapImage implements its backing off mechanism to avoid updating the decoder and invalidating the renderers too often.

So we have a problem with all images on WK1 and for ImageDocument for WK2. If the image is big and is received in many small chunks, in these cases the performance will be very slow. Updating the decoder with the new data and repainting the image renderers are very expensive operations and should be backed off. https://bugs.webkit.org/show_bug.cgi?id=175890 fixes these issues by enabling the backing off mechanisms to all platforms and for all images. The patch there has the following pros and cons:

++ It applies a strategy, which has been used for long time on iOS, to all platforms.
++ It lets every party applies its own preferable rules for buffering and backing off. WK2, buffers the image data to save the IPC calls. Wk1 does not need to do this buffering since everything is in the same process. CachedImage updates its data with the new loaded data when it arrives. But it does not update the decoder or repaints the renderers with the same rate of incoming the data.

-- It splits the logic of buffering/backing off into two places for sub-resource images on WK2. While it applies the backing off mechanism only to the other cases.
-- It makes the buffering in the Network process happens with a different rate from the backing off in the CachedImage. The buffering happens at linear rate of 500_ms. While the backing off happens at exponential rate.
-- It makes the code a little bit harder to follow especially for WK2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171006/0ec1dae5/attachment-0001.html>