Problem with rendering animated page elements, windows 7 x32/x64

[billi857]

Starting with version 122(R6) and including the current version 126(R6), I have noticed an issue with rendering animated elements on the page. If there is any animated element on the page (on any page of any website), it starts to consume a lot of processor resources (and the browser interface itself starts to slow down even more), disproportionately much, while the element is in direct visibility. This could be an animated .gif, .swg, etc., such as a loading circle (as in the screenshot) or an animated user profile avatar.
Any combination of flags, including using --force-lazy-compositor, does not solve the problem.

As far as I understand now, the essence of the problem is the following:
if there is an animated element (any) on the page, the browser window starts to be constantly completely redrawn, which creates a large constant load on the equipment. And with the correct behavior of the browser, only the fragment with the animation should be redrawn. While searching for information I found out about Partial Raster and Partial swap. So, if in version 122(R5) (where my problem is not) I disable Partial swap, then a very similar problem occurs! Although in versions 122(R6)-126(R6) Partial swap seems to be enabled...

I used to think that Skia patches were to blame, since this rendering issue is also present in the Thorium_SSE3_122.0.6261.171 browser (Supermium and Thorium use the same patches, so the problems are the same). But in version 126(R6) Skia patches were not used, and the problem remained, the reason is something else. Blaukovich's browser versions do not have this problem.
Now I believe the cause of my problem is related to the solution of this issue: #573
That is, one problem was solved, but another one arose, since in version 122(R5) my problem did not yet exist.

I have previously described this problem here: #889
But perhaps the description was not entirely clear, due to my level of competence. Now the problem has become a little clearer to me and I decided to highlight it in a separate topic, since it is important.

The hardware on which the problem is reproduced:

1. Windows 7 x32 (with all updates), CPU: Intel Atom N270 (1 core, 2 threads), GPU: Intel GMA 950, RAM: 2gb;
2. Windows 7 x64 (with all updates), CPU: Intel Atom D525 (2 cores, 4 threads), GPU: Intel GMA 3150 and Nvidia ION2, RAM: 8gb.
   Hardware acceleration is disabled in the browser settings; enabling it does not solve the problem.
   DWM is disabled, enabling it and using Aero theme does not affect the problem.

[win32ss]

The issue mentioned above was fixed by patching D3D11VideoDecoder, which isn't used below Windows 8 at this time. However, a special chrome.dll was made for this change between 122 R5 and R6. How does 122 R5 (or R6) work with this DLL in use: https://github.com/win32ss/supermium/releases/tag/win81-test-r0

[billi857]

How does 122 R5 (or R6) work with this DLL in use: https://github.com/win32ss/supermium/releases/tag/win81-test-r0

The problem with this DLL is exactly the same as I described. That is, in 122(R5) I replaced the DLL with win81-test-r0 and the problem is already present.
This test was carried out on:
Windows 7 x64 (with all updates), CPU: Intel Atom D525 (2 cores, 4 threads), GPU: Intel GMA 3150 and Nvidia ION2, RAM: 8gb.
Hardware graphics acceleration is disabled, DWM is disabled.

[win32ss]

Two chrome.dll variants have been uploaded with the V8 changes from that time reverted: https://github.com/win32ss/supermium/releases/tag/v126-v8-test-1

[billi857]

Two chrome.dll variants have been uploaded with the V8 changes from that time reverted: https://github.com/win32ss/supermium/releases/tag/v126-v8-test-1

I tried both libraries: nothing changed compared to the standard DLL 126(R6), that is, the problem remained the same.

Blaukowicz's versions had V8 security patches applied, but my specific issue (rendering animated elements) was not present in his versions. Although the browser interface also generally slows down a little, but less than in Supermium 126 and in these two test DLLs.