search

win32ss / supermium

Chromium fork for Windows XP/2003 and up
https://win32subsystem.live/supermium/
BSD 3-Clause "New" or "Revised" License
2.31k stars 78 forks source link

Sluggish behaviour in UI after update from 124 R2 to 126 R2+Hotfix (edit!) #889

Open shaft17 opened 1 month ago

shaft17 commented 1 month ago

[edit] I made a mistake! I have updated from 124 R2 to 126 R2+Hotfix All 126 releases have the lagging bug on my system, either 32bit or 64bit, have checked all.

Describe the bug After I have updated newest (126 R2 64bit) 124 R2 to R2+Hotfix 64bit via Installer, the UI of Supermium feels slow. When I hit f.e. CTRL+L to jump to the URL bar and type something, the letters I typed start to show after ~1 second.

I went back to 124 R2 and the problem is gone.

Desktop (please complete the following information):

jimjonesbased69 commented 1 month ago

That sounds awfully close to my own issue (https://github.com/win32ss/supermium/issues/878), minus the 126 without hotfix running normally on your end. Odd.

tessa112 commented 1 month ago

I have noticed slow/sluggish menu renderings on both 126 & 126R2 32bit running on a fully updated Win7 64bit OS. Compared to 124 it is a pretty big difference but other than that it seems to be running just fine.

jimjonesbased69 commented 1 month ago

@tessa112

That's precisely my issue too. I'm... "glad" that someone else ran into this issue as well, I was starting to doubt my sanity here.

shaft17 commented 1 month ago

@jimjonesbased69 Yeah, I saw your bug report but as I observed the "lags" only after updating from R2 to R2+Hotfix, I thought it would be worth it to open a new ticket. Something strange is going on here, don't know what it is.

shaft17 commented 1 month ago

I'm so sorry for the confusion. Long story short: All 126 releases are lagging on my Win 7 64bit system. The 124 R2 works! I have updated the title and the first post.

jimjonesbased69 commented 1 month ago

@shaft17

I was wondering why i've never seen that non-hotfix R2 you've been talking about. Well, that explains it. Let's hope @win32ss is able to reproduce this issue and find the cause.

kda2495 commented 1 month ago

I confirm, on 126 R3 all works with lags on sites when I scrolling or something else. @win32ss Hope, that you will find how to solve this issue and make R4 update))

kda2495 commented 1 month ago

Pages were lagging for a while (several hours), but then everything stopped and works fine, even after a reboot. Strange.

Ravenant1234 commented 1 month ago

[edit] I made a mistake! I have updated from 124 R2 to 126 R2+Hotfix All 126 releases have the lagging bug on my system, either 32bit or 64bit, have checked all.

Describe the bug After I have updated newest (126 R2 64bit) 124 R2 to R2+Hotfix 64bit via Installer, the UI of Supermium feels slow. When I hit f.e. CTRL+L to jump to the URL bar and type something, the letters I typed start to show after ~1 second.

I went back to 124 R2 and the problem is gone.

Desktop (please complete the following information):

  • OS: Windows 7 64bit

that behaviour is weird

idk why thts happening..... do u have the platform update for windows 7 (KB2670838) ?

Ravenant1234 commented 1 month ago

I have noticed slow/sluggish menu renderings on both 126 & 126R2 32bit running on a fully updated Win7 64bit OS. Compared to 124 it is a pretty big difference but other than that it seems to be running just fine.

Fully updated??!!!

jimjonesbased69 commented 1 month ago

@Ravenant1234

I can personally confirm that update status has absolutely no bearing on this issue.

tessa112 commented 1 month ago

I have noticed slow/sluggish menu renderings on both 126 & 126R2 32bit running on a fully updated Win7 64bit OS. Compared to 124 it is a pretty big difference but other than that it seems to be running just fine.

Fully updated??!!!

well, almost.

image

MizaGBF commented 1 month ago

I just updated Supermium to the latest version (126 R3, 64 bits) on my win8.1 machine. I haven't experienced anything as described here. The browser did feel off just after installing however (which prompted me to check if anything was going on here, in the issues). Especially:

But, beside this, it ran fine. I wasn't on a fresh profile and I can't discard a possible nocebo effect on my part, I'm just sharing my experience. I played around with flags since because I didn't really like the new look, and I currently have:

ntp-realbox-cr23-all disabled
ntp-realbox-cr23-theming disabled
chrome-refresh-2023 disabled
force-xp-theme enabled

and I haven't noticed these problems again, it's now buttersmooth. I don't know if enabling the classic theme helped, though.

tessa112 commented 1 month ago

This should be an easy way to try to reproduce,

When i click a folder on the bookmark bar it takes ~1 second to display the content (15-20 dirs and ~100 bookmarks) and moving the cursor up-down it only highlights every 4-5th instance. (very laggy, always been instant prior to v126) Trying to list another subdir containing 10 bookmarks will take again ~1 second. (i can even perceive the window fade in)

jimjonesbased69 commented 1 month ago

I've just finished testing Windows XP 64-Bit Edition (x64), Windows Vista (x64), Windows 7 (x64), 8 (x64), 8.1 (x64), 10 (x64) & 11 (x64). It appears that only Windows 7, 8 & 8.1 are affected by this issue, all other operating systems ran fine and no sluggishness could be observed at all.

Half-Modern commented 1 month ago

Disable Aero and see what happens.

jimjonesbased69 commented 1 month ago

@FK2FAGHMS

There is no difference between Aero, Basic & Classic theme performance, the issue persists throughout.

Half-Modern commented 1 month ago

Weird, I did not expect any sluggish performance (Classic/Pre-Refresh). Maybe the ones whose experiencing this problem should list system specifications like CPU, GPU and drivers (see if there's any similarities).

jimjonesbased69 commented 1 month ago

@FK2FAGHMS

I'm almost positive that this can't be a hardware problem as Supermium runs normally on all operating systems, barring Windows 7, 8 & 8.1, while the hardware it's running on remains the same.

jimjonesbased69 commented 1 month ago

Okay, i've potentially discovered what causes this behavior. Here's what i've found:

Running Windows 7 (x64) in VMware:

Running Windows 7 (x64) on Hardware:

Could someone that experiences this issue please uninstall their graphics driver via DDU and report back if they run into the same results?

MizaGBF commented 1 month ago

I don't want to play around with the graphic driver of this machine for reasons but:

Half-Modern commented 1 month ago

Well, I forgot to mention that I've used the 32-bit version of the browser. My GPU is NVIDIA Geforce GT 220M and with drivers 342.01. I didn't test the 64-bit version because it's more resource intensive and my machine is limited to 4 GB of RAM.

win32ss commented 1 month ago

Okay, i've potentially discovered what causes this behavior. Here's what i've found:

Running Windows 7 (x64) in VMware:

* With VMware graphics driver installed = Sluggishness.

* **Without** VMware graphics driver installed = **No** Sluggishness.

Which version of VMware Workstation/Player is this? And which hardware compatibility setting is used? I didn't have any issues with WS 12 with the same hardware compatibility level.

I also received results from an Intel HD user who only had sluggishness when moving the window around.

Here is the 124 renderer, which works with 126: old_renderer.zip

jimjonesbased69 commented 1 month ago

@win32ss

I'm using VMware Workstation 15 Pro (15.5.7 build-17171714) using a Windows 7 (x64) host.

I setup all my virtual machine guests with these settings:

As for the older renderer you've supplied, it sadly doesn't appear to be changing anything on my end.

win32ss commented 3 weeks ago

I set up a Windows 7 install on a system with a NVIDIA Quadro K2200 running driver 348.40 and there were no performance issues. But it seems I don't remember suggesting temporarily removing dwrite.dll from the Supermium folder. I wonder what happens if it's removed altogether?

jimjonesbased69 commented 3 weeks ago

@win32ss

Do you have access to slighty newer hardware which works with the latest drivers? Or, can you use more recent drivers that support that graphics card? Via NVIDIA's driver page, your card should be able to use the R440 U4 (441.66) driver, no? But this makes me think; @FK2FAGHMS has similarly old drivers and is also not affected by this issue, maybe old NVIDIA hardware/driver configurations are unaffected?

I've tested these hardware configurations:

(Modern NVIDIA) GTX 1660 Super with 472.12 drivers. (Radeon GCN) RX 580 with 21.4.1 drivers. (Radeon TeraScale) Radeon HD 8650G with 15.7.1 drivers. (Virtual) VMware with whatever driver Workstation 15 Pro provides.

Coincidentally, I do not own any old NVIDIA hardware.

Removing the DWrite library was actually the first thing I did trying to fix the issue, no dice. Was a moonshot anyway since 124, which also shipped with the library, had no issues at all.

I'd also like to ask again; if anyone with this specific issue could uninstall their graphics drivers via DDU and report back if that remedies this issue, that would be great.

win32ss commented 3 weeks ago

I installed 441.66 and nothing changed.

My next attempt will involve internal tests with other users experiencing the same issue, but with Chromium 124-126 era nightly builds patched to run on Windows 7 using the binaries earmarked for Superfox. I had actually discovered many different feature switches relating to compositing, message loops and related entities that were introduced in this period but none had any impact, leaving no other option than to pore over potentially dozens of nightly builds to find the responsible commit amongst the sprawling Chromium codebase.

billi857 commented 3 weeks ago

All 126 releases are very slow on my hardware (the interface is very slow compared to 124 and 122). Win 7 32bit Starter (Aero is not there, DWM service is disabled), updates until 2024. CPU: Intel Atom N270 (two logical cores) / 2GB RAM / GPU: Intel GMA 950. Hardware acceleration is disabled in the browser settings, because GMA 950 is useless and only harmful. Versions 122 and 124 are fast. 124 is a little slower than 122, but I use the 122 version, because 124 has strange problems with YouTube (the video won’t start, no matter what I do, the wheel just spins, and the same thing with the 126 version).

billi857 commented 2 weeks ago

@win32ss

Let me give you a simple example of a rendering bug on my equipment. It seems to me that this may also be due to the slowdown of the interface, because in version 124 it has already become slower, but to a lesser extent than in 126.

So, you need to disable JavaScript in your browser settings and open the page: https://github.com/win32ss/supermium/releases Under the newest release you can see an animated circle (since JavaScript is disabled, the circle will continue to spin, but the “Assets” list will not appear).

Rendering this small element (while it is present in line of sight) uses the CPU over 50% and tries to use the GPU, even with hardware graphics acceleration disabled. This happens in versions 126, 124 and 122(R6). In version 122(R5), 122(R4), 122(R2) everything is fine and works as it should. From this it follows that, for my equipment and similar ones with win7, the rendering became corrupted already in version 122 (R6), and this got worse in subsequent versions.

Details can be seen on the screenshot. Those who have problems with the slow interface can repeat this experience. It would be interesting to know the results and establish or refute the relationship. Of course, CPU usage will be more noticeable on weaker hardware. supermium render bug

win32ss commented 2 weeks ago

I recently made heavy patches to a Chromium 126/early 127 nightly build so it could run on Windows 7/8.1. A user tested this build and had no UI slowdown issues. So I decided to start looking into Supermium's own patches as the ultimate cause of the issue.

And this most recent submission would prove it, as virtually all non-security patches between 122 R5 and R6 originated from Supermium itself. The most relevant change would be the change to "non-lazy composition", as it solved some drawing bugs that were once present, while not causing any reports of performance issue (my testing systems have no change in performance between 126 R3, 126 R3 with lazy composition, and 122 R5). The old functionality remains available behind the command line switch --force-lazy-compositor, so users may want to try it. If so, the switch will be retooled and the resulting effect will switch from opt-out to opt-in.

tessa112 commented 2 weeks ago

Unfortunately the --force-lazy-compositor switch did not resolve the problem for me on 126R2. (win7 x64 32GB RAM with a GT 1030 card on 473.62 whql driver)

billi857 commented 2 weeks ago

@win32ss

The most relevant change would be the change to "non-lazy composition", as it solved some drawing bugs that were once present, while not causing any reports of performance issue (my testing systems have no change in performance between 126 R3, 126 R3 with lazy composition, and 122 R5).

I've already used --force-lazy-compositor. Unfortunately, this does not affect the problems described above and the slowdown of the interface.

"lazy composition" gives benefit to weaker hardware when you open a link in a new tab and don't switch to it while it's loading. Thus, rendering does not occur and does not eat up the power of the equipment until you switch to this tab. Without --force-lazy-compositor, loaded background tabs use more power and time (probably only noticeable on very low-end hardware like mine).

I tried playing with some other flags related to rendering and layout, but to no avail. Clearly the problem is something else that was introduced/changed in 122(R6) but was missing or not addressed in 122(R5). But from the description of the changes in 122(R6) the reason is unclear to me, even approximately...

win32ss commented 2 weeks ago

The other changes not related to UI metrics in 122 R6 were some small GDI compatibility fixes in the Skia renderer and the print/PDF renderer, as well as the patching of security vulnerabilities in the V8 renderer.

jimjonesbased69 commented 2 weeks ago

@win32ss

Your patches for Supermium are not the cause of this issue, it's chromium itself. Checking out various plain patches that make newer chromium versions work on older operating systems, i've noticed that the issue appears somewhere between 124.0.6364.202 (https://github.com/Blaukovitch/GOOGLE_CHROME_Windows_7/releases/tag/124_ret2) and 125.0.6422.61 (https://github.com/Blaukovitch/GOOGLE_CHROME_Windows_7/releases/tag/125). Both have the same new UI, but only 125 exhibits the issue.

win32ss commented 2 weeks ago

I have now patched two nightly builds of Chromium 126/127 from April 30 and May 16, 2024 to run on Windows 7. The user noticed that tab animations were slow in the April 30 build, but not menu highlights. No issues were present in the May 16 build. (126 ESR "feature" patches are mostly frozen in the mid April - mid May period)

I am going to patch further builds but this process may be lengthy, as there are about 8000 commits between the two releases, and especially hastened by the fact I have to rely on others' hardware to test (and this particular user is in the path of Hurricane Milton!)

I'll probably end up simplifying the patching process to allow users to self-test the nightly builds from the Chromium browser snapshot repository, using a divide-and-conquer strategy.

win32ss commented 1 day ago

I patched several nightly builds between versions 124 and 127. None of them had the extent of performance issues that Supermium and Google Chrome experience. The difference seems to lie in build options (Supermium and Google Chrome are a more release-oriented configuration, while the nightly builds, while not being built with debug flags, have more sanity checking and logging enabled, including dumps and call stacks being dumped on the command line without line numbers). For that reason I built a debug build of Supermium,

I'll correct as many issues as I can find with the debug release and then release a regular non-debug release with these changes.