This will not materially improve performance, which is why Apple never shipped it in the first place. All browser rendering is already done using a highly optimized library that already utilizes OpenGL.
No, it will not necessarily decrease loading times or rendering throughput, but
some did notice a minor improvement in graphical smoothness in the TenFourFox-based browsers, at least on weaker systems, and anecdotally, I also observed a moderate reduction in graphical stuttering and I
think slightly less resource consumption after the flag was enabled. And particularly if hardware acceleration is to be disabled on 10.4 going forward, it could be a valuable addition to offset the increased load on the CPU.
I merely thought to raise the suggestion since Aquafox also used it by default (alongside some other tweaks, like the custom prefs file) and was in most cases the relative fastest / smoothest fork of TenFourFox yet despite the chronic absence of GPU support. But of course, that was all on the FF45 codebase rather than UXP. Indeed perhaps more granular A/B testing on broader configurations would be prudent before shipping it as a default here.
And for the record, Apple did ship QuartzGL selectively in certain graphics-centered applications in at least 10.5 to smooth out UI animations, including Grab, Preview, and System Preferences; case in point the latter of which will heavily stutter between preference pane transitions if QuartzGL has been disabled in Info.plist (if memory serves). What they did not do is enable it system-wide and market it as a new feature but rather used it sparingly as a stopgap measure and later replaced it altogether as the capabilities of Core Image, et al became more deeply integrated to the OS.
This is already done, check about:buildconfig.
My apologies, I should have rephrased this. I understand that the sse3 flag is present in the build config, but the issue is that about:support is seemingly only honoring the CPU's capabilities as limited to SSE2. Is it because the target CPU has been set to pentium-m rather than something else like core? Or is this the expected behavior?
This will not be done as all 64-bit Macs deserve the ability to run the 64-bit build. As such, 64-bit builds are optimized for the Conroe microarchitecture, check about:buildconfig. ... This isn't really true, there would only really be a minimal performance increase (if one were to happen at all) and the slowest parts of the browser don't depend on SIMD either way.
Fair enough. I simply figured it might consolidate the number of builds if that's any easier.
Lastly, I was wondering if any of the other compiler optimizations used in
Thorium would be applicable to UXP as well? I recall Cameron Kaiser discussing adding LTO and PGO optimizations to older builds of Firefox several years back, so maybe a few of them could be used here also.
Just wanted to contribute some areas of potential improvement, that's all.
