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.