My Browser Builds (Part 4)

[legacyfan]

34 minutes ago, mina7601 said:

This is so good!

good job roytam1 as usual!

[Skorpios]

Serpent52/55 and MP68 are showing jxl-files with version 0.1 of this extension:
https://addons.mozilla.org/en-US/firefox/addon/jxl/versions/
https://github.com/zamfofex/jxl-crx

---

https://jpegxl.info/test-page/

Row 1 and 2: WebP, jpg and png loads instantly, the jxl file shows up about 10! seconds later with Serpent. With MP68 I'll have to wait about 15 seconds!!!... probably my outdated door stop is the cause. Thinkpad T43/Pentium M760/2GB RAM/Radeon X300...

Row 3: Four red squares?

Row 4: the jxl is not spinning
.

 

Edited June 26, 2023 by Skorpios
spelling...

[Mathwiz]

9 hours ago, VistaLover said:

FWIW, it doesn't even work in St52 if:

a. You disable the native WebP decoder, by toggling "image.webp.enabled"
b. Modify "image.http.accept" in the way you suggested...

Serpent may be a somewhat different beast. It (well, at least St 55) has a second pref, network.http.accept.image (that I guess MCP added), but I don't know what it does as compared to the pref inherited from FF. But in any case, the FF 52 experiment showed that Bing isn't smart enough not to send WebP to a browser that indicates it doesn't want WebP. Extremely bad practice, indeed.

Back to JPEG XL. I tried to update Paint.net on my Win 7 system last night to a version that supports JPEG XL (which happens to be the last Paint.net version for Win 7), and discovered the author meanly removed all but the latest (Win 10+) version from his GitHub page. I tried to find the needed version, but the only installer I could find is an "online" installer and it kept getting a stupid SSL error. I don't have time for that kind of nonsense, so I just uninstalled Paint.net and switched to Gimp.

Gimp isn't as user-friendly, but it still runs on Win 7 and it includes a JPEG XL plugin. I loaded in a big 3.3MB .PNG image and exported it as .JXL. The two images look identical to my (admittedly untrained) eyes, but the .JXL one was about 1/4 the size of the .PNG. Wow - no wonder folks want to switch!

[VistaLover]

32 minutes ago, Mathwiz said:

It (well, at least St 55) has a second pref,
network.http.accept.image
(that I guess MCP added), but I don't know what it does
as compared to the pref inherited from FF.

Yep, St52 does have that, too:

As one can see, there's duplication inside the "value" column, but only "image.http.accept" mentions webp ...

[VistaLover]

49 minutes ago, Mathwiz said:

pref, network.http.accept.image (that I guess MCP added),

See UXP #993 ...

[roytam1]

1 hour ago, Mathwiz said:

I tried to update Paint.net on my Win 7 system

you need 4.3.12. https://portableapps.com/apps/graphics_pictures/paintdotnet-portable#download_details

[Mathwiz]

4 hours ago, Skorpios said:

Serpent52/55 and MP68 are showing jxl-files with version 0.1 of this extension....

Row 1 and 2: WebP, jpg and png loads instantly, the jxl file shows up about 10! seconds later with Serpent.

Probably, the extension uses JavaScript to decode JPEG XL, which is probably a lot slower than a JPEG XL decoder written in C or C++.

1 hour ago, roytam1 said:

you need 4.3.12. https://portableapps.com/apps/graphics_pictures/paintdotnet-portable#download_details

Yes, 4.3.12 was the version I was looking for.

I did stumble across it at portableapps.com, and wondered if they had the full version vs. just an "online" installer that wouldn't work. But portableapps.com has their own "PortableApps Platform" which looked like yet another complication. Turns out you don't have to use it, but I also figured a "portable" app wouldn't upgrade my existing app or keep my settings. After all, by definition a "portable" app is designed to be installed on and run from a thumb drive.

Besides, I was already disgusted with dotPDN's attitude. I didn't mind that they stopped supporting Win 7, but what really irked me was that they went out of their way to erase their last Win 7 version from as much of the Internet as possible, so if you didn't upgrade in the days between 4.3.12 and 4.4, you were SOL. Reminded me of too many folks' attitude towards XP/Vista: "We've decided not only to stop supporting it, but that you shouldn't be using it, so we're going to do as much as we can to pressure you to 'upgrade.'"

Oh - and Paint.net 4.3.12 doesn't come with the JPEG XL plugin - you have to add that later yourself. Switching to Gimp was a lot less work.

[nicolaasjan]

2 hours ago, Mathwiz said:

Besides, I was already disgusted with dotPDN's attitude. I didn't mind that they stopped supporting Win 7, but what really irked me was that they went out of their way to erase their last Win 7 version from as much of the Internet as possible, so if you didn't upgrade in the days between 4.3.12 and 4.4, you were SOL. Reminded me of too many folks' attitude towards XP/Vista: "We've decided not only to stop supporting it, but that you shouldn't be using it, so we're going to do as much as we can to pressure you to 'upgrade.'"

Web Archive has all 4.3.12 flavours :

https://archive.org/details/paintdotnet_v4_3_12.

[UCyborg]

On 6/26/2023 at 6:39 AM, nicolaasjan said:

(offtopic)

Possibly due to recent changes in YouTube's site code?

Maybe try with the latest versions of youtube-dl or yt-dlp, optionally with the help of the legacy "Open With" extension.

Direct link to legacy XUL version:

https://ca-archive.us.to/storage/11/11097/open_with-6.8.6-fx+sm+tb.xpi

Screenshot.

Indeed there was a change. Thanks, I'm aware of other options, just never got around to set any of them up as the extension always worked well enough.

I managed to fix the old XUL Ant Video Downloader extension yesterday, the code that captures the stream URL, I changed it so it removes ump=1 parameter. No clue what it does, didn't dig into it, guess it appends something extra that their client understands. The content type of that "UMPed" stream it sends with that parameter is application/vnd.yt-ump.

Edited June 27, 2023 by UCyborg

[VistaLover]

12 hours ago, Mathwiz said:

Probably, the extension uses JavaScript to decode JPEG XL,
which is probably a lot slower than a JPEG XL decoder written in C or C++.

... Actually, it uses Web Assembly (aka wasm) to do it :

https://github.com/zamfofex/jxl-crx#readme

Quote

It uses a WebAssembly implementation of libjxl.

 

12 hours ago, Mathwiz said:

Besides, I was already disgusted with dotPDN's attitude. I didn't mind that they stopped supporting Win 7, but what really irked me was that they went out of their way to erase their last Win 7 version from as much of the Internet as possible, so if you didn't upgrade in the days between 4.3.12 and 4.4, you were SOL.
Reminded me of too many folks' attitude towards XP/Vista:
"We've decided not only to stop supporting it, but that you shouldn't be using it, so we're going to do as much as we can to pressure you to 'upgrade.'"

... Disgust echoed in the "archive.org" reviews/comments:

Quote

Reviewer: GGigabiteM - 5 stars - June 25, 2023
Subject: Thank god someone archived it.

I was hunting for this release everywhere and thankfully someone had archived it, most specifically the x86 version.

The more research I've done to try and find this version, the more evidence I find that Rick Brewster is a supreme a**hole. He actively goes out of his way to spite people that need old versions of his software by deleting them as soon as a new release comes out, and pushes the Windows Store version and the online web download that doesn't store any files on the local machine until it is actually downloaded.

He also bans and silences anyone on his forum asking for such, even going as far to make rules forbidding it. He's free to be an a**hole on his own forum, but I'll definitely be looking for alternatives now that I know he's on the same level as Steve Jobs, a terrible person.

... And one thing mentioned in that quote above that seems to be the new "vogue" among app authors is the deprecation of 32-bit binaries (latest Paint.NET runs exclusively on Win10/11 64-bit), a development I face all the more lately when searching for Windows binaries (of various software) compatible with my x86 OS... I mainly blame MS and their latest OS, available solely as 64-bit ...

Edited June 27, 2023 by VistaLover
redundant whitespaces removed

[RamonUn]

On 6/27/2023 at 5:12 PM, VistaLover said:

... And one thing mentioned in that quote above that seems to be the new "vogue" among app authors is the deprecation of 32-bit binaries (latest Paint.NET runs exclusively on Win10/11 64-bit), a development I face all the more lately when searching for Windows binaries (of various software) compatible with my x86 OS... I mainly blame MS and their latest OS, available solely as 64-bit ...

I do not like it much either, there are still plenty of 32bit Windows, I have even see several 32 bit Win10 laptops that were not up-gradable to 64 bit because of UEFI BIOS. So in the end I think there are more 32bit windows than Linux desktops. Even if all AMD/Intel CPUs have been 64bit since the early 2000s...

Also I always saw the duality or architectures as a free sanitizer, you would be surprised on how many subtle bugs can be found by just building and testing in both 64bit and 32bit. There were a lot of buggy 32 bit programs that were hard to port to 64bit and now I see random programs that have a ton of warning simply when you build them for 32bit and some of them cannot even work. Bad coding habits still exist but have just migrated from :"I assume my CPU is 32bit so int == void* and stuff" to "I know my CPU is 64bit so uint64_t == void* and stuff".

Windows 10 will be supported until 2025 (and possibly beyond), so dropping 32bit support is very strange because it is still maintained by Microsoft.

[UCyborg]

Nothing new, especially when you look beyond conventional computers. Guess 32-bit is going the same way 16-bit did once. I remember 64-bit games started appearing in a more mainstream fashion back around 2014. That's almost a decade ago. Apple's last OS with 32-bit support was macOS Mojave from 2018, mainstream Linux distros did it around 2015-2018, it was only a matter of time when Microsoft would follow. There's still WOW64 on Windows. Intel was ambitious and wanted to give us pure 64-bit arch back then (IA-64), but it failed. Wouldn't it make hardware design simpler?

Statistically, 32-bit is simply outnumbered and it hardly makes sense to load 32-bit OS on a half-decent computer in probably a vast majority of cases. Heck, mine didn't even cost 1000€ back in 2009 and I haven't really ran anything but 64-bit systems on it. Hardly anyone who talked about building a decent new rig back then suggested putting 32-bit OS on such, unless he was drunk.

3 hours ago, RamonUn said:

Bad coding habits still exist but have just migrated from :"I assume my CPU is 32bit so int == void* and stuff" to "I know my CPU is 64bit so uint64_t == void* and stuff".

Shouldn't they be using PVS-Studio or something to catch those?

Edited June 29, 2023 by UCyborg
More accurate years of last 32-bit Linux distros

[RamonUn]

19 minutes ago, UCyborg said:

Statistically, 32-bit is simply outnumbered and it hardly makes sense to load 32-bit OS on a half-decent computer in probably a vast majority of cases. Heck, mine didn't even cost 1000€ back in 2009 and I haven't really ran anything but 64-bit systems on it. Hardly anyone who talked about building a decent new rig back then suggested putting 32-bit OS on such, unless he was drunk.

I agree 32bit OS should not be there anymore but I still do see them because of stupid OEM vendors that sell bad stuff cheaper and many people that have lillte budjet end up with this. Microsoft is willing to drop 64 bit since vista, but the vendors decided otherwise.

I am unsure it would save much on CPU because the 1) the actual computing unit is a minority on a modern CPU, 2) 64 bit mode still allows you to use most 16/32bit instructions so they will be parsed almost the same. The only thing you are saving is some very specific circuits related to cpu modes, I am not a CPU designer however. Probably there would be advantages to drop support for 32bit mode on future CPU but at this point I think the x86 architecture is close to its end even if dropping 32bt mode were to save significant cost.

Intel did take the good decision to abandon the avx512 instruction set that was HUGE and completely unused by 99.9% of programs for the simple reason that not enough CPU were equipped.

 

28 minutes ago, UCyborg said:

Shouldn't they be using PVS-Studio or something to catch those?

It will most of the time but many people are not even using the compilers' warnings and even the warnings will not catch many things. for example I have seen people use %lld format with printf to print an address in 32bit mode you do get a warning but not in 64bit mode.or they use a win32 LPARAM cutting it in two 32 bit DWORDS and this fails if you are compiling in 32bit mode because LPARAM is 32bit only in 32bit mode. In this later case it would require a real change not just changing a type. May popular open-source projects however to their best.

When I program I use all warnings, several compilers and I still make this kind of mistakes occasionally that I catch when building in 64bit mode, but I admit I am a terrible programmer.

[roytam1]

New build of Serpent/UXP for XP!

Test binary:
Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20230701-3219d2d-uxp-4fae28f05-xpmod.7z
Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20230701-3219d2d-uxp-4fae28f05-xpmod.7z

source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom

IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20230701-3219d2d-uxp-4fae28f05-xpmod-ia32.7z

source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32

NM28XP build:
Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20230701-d849524bd-uxp-4fae28f05-xpmod.7z
Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20230701-d849524bd-uxp-4fae28f05-xpmod-ia32.7z
Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20230701-d849524bd-uxp-4fae28f05-xpmod-sse.7z
Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20230701-d849524bd-uxp-4fae28f05-xpmod.7z

Official UXP changes picked since my last build:
- Issue #1956 - Allow building with newer MSVC versions. (ccd69e165)
- No issue - Set the default for incremental cycle collector to be off. (c4d665a0d)
- Issue #1691 - Follow-up: Print leaking class name and remove crash reporter dependency (fe7244c01)
- No issue - Update SQLite lib to 3.42.0 (865845230)
- Issue #21 - Part 1: Remove experiments base code from the Add-ons Manager (369e68a66)
- Issue #21 - Part 2: Remove experiment extension assets and styling (9f8aa81a8)
- Issue #21 - Part 3: Remove experiments localization (341632f86)
- Issue #21 - Follow-up: Remove experiment category images (6444835ac)
- Issue #1769 - Part 1: Add vendored libjxl and highway sources. (7983f5d8b)
- Issue #1769 - Part 2: Implement JPEG-XL decoder and about:config and MIME plumbing. (51ea0e4f3)
- Issue #1769 - Part 3: Cleanup nsJXLDecoder. (2df558509)
- Issue #1769 - Part 1 Follow-up: Tidy up moz.build for highway and libjxl (00a5d6401)
- Issue #1769 - Part 2 Follow-up: Do not use namespace parent::child {} for defining nested namespaces. (134c5e94e)
- Issue #1769 - Part 1 Follow-up: Use standard [[deprecated]] for JXL_DEPRECATED. (40f27cd35)
- Issue #1769 - Follow-up: Fix typo in MOZ_ARG_ENABLE_BOOL (4d78f53da)
- Issue #1769: Update symbols for libxul linkage (1ef390db0)
- Issue #1769: Ensure MIME type is known in URIloader for jxl (f860413ed)
- Issue #1769 - Follow-up: Default-enable JPEG-XL images if built (7f87cc127)
- Issue #2033 - Temporary fix of R<->B channel swap. (77ca4ae9d)
- fix whitespace. (8b4b6f8eb)
- Issue #2040 - Pre-multiply the alpha values in our JXL decode buffer. (9b4c0ef4e)
- Issue #2041 - Add animation support for JPEG-XL. (042b8f37a)
- Issue #2048 - Add progressive decoding for JPEG-XL. (0bd6f0035)
- Issue #2041 Follow-up - Remove opacity check from original patch. (54e073511)
- PR #2050 follow-up: add symbols to build shared on Windows. (514ed1423)
- Issue #2041 follow-up - fix macro condition (8f0916289)
- Issue #2057 - Use gfxPackedPixel + WritePixels instead of WriteBuffer. (42543c12f)
- Issue #2061 Follow-up: Export jxl/version.h. (b18114517)
- Issue #2061 Follow-up: Fix moz.build to compile on all platforms. (743d1f66d)
- Issue #1382 - Fix invalid assert for decoder type if JXL is not built on debug builds (06d2df29b)
- Issue #2061 - Follow-up: Silence compiler warnings for libjxl (84dc161d5)
- Issue #2061 - Follow-up: Silence compiler warnings for libjxl (MSVC) (80c206284)

No official Pale-Moon changes picked since my last build.

No official Basilisk changes picked since my last build.

My changes picked since my last build:
- bump platform version for JPEG-XL import (c0c980e12)
- bump PM version as well (f191eae65)
- moz.configure: add fix for VS2017 x64 ATLMFC lib path detection (661754041)

 Update Notice:
- You may delete file named icudt*.dat inside program folder when updating from old releases.

* Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

[roytam1]

New build of BOC/UXP for XP!

Test binary:
MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20230701-ef491d91-uxp-4fae28f05-xpmod.7z
BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20230701-ef491d91-uxp-4fae28f05-xpmod.7z

source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom

* Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15.

--

New build of HBL-UXP for XP!

Test binary:
IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20230701-id-656ea98-uxp-4fae28f05-xpmod.7z
IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20230701-id-656ea98-ia-93af9a0-uxp-4fae28f05-xpmod.7z

source repo (excluding UXP):
https://github.com/roytam1/icedove-uxp/tree/winbuild
https://github.com/roytam1/iceape-uxp/tree/winbuild

for UXP changes please see above.