Leaderboard

New NewMoon 27 Build! 32bit https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210807-1d0f42f44-xpmod.7z 32bit SSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210807-1d0f42f44-xpmod-sse.7z 32bit noSSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210807-1d0f42f44-xpmod-ia32.7z 64bit https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20210807-1d0f42f44-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - updated some user-agent overrides (76c1d5521) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1061525 - Part 1: Add support for planar MacIOSurfaces. r=BenWa (fc5a088be) - Bug 1061525 - Part 2: Make MacIOSurfaceTextureHostOGL understand planar MacIOSurfaces. r=jrmuizel (c4d50d77a) - Bg 1061525 - Part 3: Add shaders for NV12 to OGLShaderProgram. r=BenWa (9f8016472) - Bug 1061525 - Part 4: Add an NV12 effect, and implement it for CompositorOGL. r=nical (750037323) - Bug 1061525 - Part 5: Make the OSX video decoders output NV12 format MacIOSurfaces. r=jya (925c3f729) - Bug 1061525 - Part 6: Add readback code for converting NV12 MacIOSurfaces into RGB. r=nical (3e32a24b6) - Bug 1061525 - Part 7: Add software backed NV12 images support. r=mattwoodrow (71e98e1e6) - Bug 1146644 - Don't assert compiling a for-loop with a const loop-variable declaration. r=shu (c785e7a17) - Bug 1168666 - Update assertions to allow export specs to contain batch exports r=waldo (2740daa74) - Bug 1168474 - Remove assorted arity-checks that are easily done another way (or not at all). r=shu (76d3efe41) - Bug 1167823 - Remove dead code for checking whether a parse tree node has side effects. r=shu (a45be013c) - add back missing PNK_POD PNK_POWASSIGN in side effect checks (9b2a4317b) - Bug 1072898 - Part 2: Enable reftest for non-accelerated layers. r=mattwoodrow (26dedc262) - Bug 1201183 - handle font family name OOM error. r=nfroyd (dc6c72ba9) (95ae6701b) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1170609 - Make the GC markers test use SpecialPowers.Cu.forceGC so it works in e10s. r=jsantell (c9efada65) - Bug 1171539 - ConsoleTime markers should render endStacks. r=vp (2b818c84b) - Bug 1141614 - Part 5: Add a test for cycle collection markers; r=jsantell (2fcf9b125) - Bug 1183579 - Inline some function needed purplexpcom. r=jduell (d4c0decb5) - Bug 1114554 - Patch 4 - ServiceWorkerRegistration.getNotifications() on main thread. r=wchen (3d2be75e5) - Bug 1114554 - Patch 5 - getNotifications() on worker thread. r=wchen (baf1bf0eb) - Bug 1114554 - Patch 6 - ServiceWorkerRegistration.getNotifications() tests. r=wchen (82978dc27) - Bug 1114554 - Patch 7 - Call BindToOwner on all threads. r=wchen (8aa9fde6b) - Bug 1114554 - Patch 8 - Support waitUntil() on notificationclick event. r=baku (0dec01fde) - Bug 1182964 - Replace use of nsTHashtable::EnumerateEntries with nsTHashtable::Iterator in layout/{style,svg}/. r=njn (cb7b75a0a) - Bug 1181321 - Eliminate duplicate mRefCnt members in PromiseNativeHandler subclasses. r=baku (1ab7687e1) - Bug 1173934 Show a message if a docshell fails to load due to SW intercept failure. r=ehsan r=jdm (fa0e3c433) - Bug 1243312 - nsNetCID is missing in toolkit/system/unixproxy/nsLibProxySettings.cpp. r=jduell (3bae88588) - Bug 1186042 - "Undeclared identifier" errors building nsAboutBloat.cpp. r=jduell (e1f5b0376) - Bug 1182976 - Part 1: Get rid of IdentifierMapEntryAddNames; r=baku (bfe3f4489) - Bug 1182976 - Part 2: Get rid of the Helper class in QuotaManager::OpenDirectoryInternal; r=janv (a2545b8fa) - Bug 1165270 - Use origin for BroadcastChannel, r=bholley (8c789d86e) - Bug 1182976 - Part 3: Get rid of PostMessageEnumerator; r=baku (61efbbc9e) - Bug 1182976 follow-up: Address njn's drive-by comment (26b345e4d) - Bug 1182978 (part 1) - Use nsTHashtable::Iterator in nsSMILAnimationController. r=birtles. (87129e7d2) - Bug 1182978 (part 2) - Use nsTHashtable::Iterator in nsSMILAnimationController. r=birtles. (d82307b24) - Bug 1182978 (part 3) - Use nsTHashtable::Iterator in nsSMILAnimationController. r=birtles. (b162c947f) - Bug 1182978 (part 4) - Use nsTHashtable::Iterator in nsSMILAnimationController. r=birtles (e6039255a) - Bug 1182978 (part 5) - Use nsTHashtable::Iterator in nsSMILTimedElement. r=birtles. (305069fe9) (a550e0f11) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1182960 (part 1) - Use nsTHashtable::Iterator in toolkit/components/telemetry/. r=mak. (ac5c34f3c) - Bug 1182960 (part 1) - Use nsTHashtable::Iterator in toolkit/components/telemetry/. r=mak. (79ea05add) - Bug 1182960 (part 2) - Use nsTHashtable::Iterator in toolkit/components/places/. r=mak. (5a059ff2d) - Bug 1182408 - Part 1: Move permission key checks out of loop. r=ehsan (a646bbe2e) - Bug 1182408 - Part 2: Use nsTHashTable::Iterator in nsPermissionManager. r=ehsan (02fe874ca) - Bug 1182408 - Part 3: Use nsTHashTable::Iterator in mozPersonalDictionary. r=ehsan (27c2dc15a) - Bug 1182961 (part 4, attempt 2) - Use nsTHashtable::Iterator in CacheFileHandles. r=michal. (79059d3e9) - Bug 1155169 - Avoid restoring the same cookie twice if the previous version of the cookie is not stale; r=jdmv (1353ef2d0) - Bug 1182961 (part 5, attempt 2) - Use nsTHashtable::Iterator in nsCookieService. r=michal. (0574f8e65) - Bug 1169880 - Recompute image visibility on a timer if layout or style flushes have occurred. r=tn (badefadbf) - Bug 1179939 - Avoid crash if we destroy the pres context during flushing style or layout. r=roc (9047cb706) - Bug 1182962 (part 3) - Use nsTHashtable::Iterator in gfxPlatformFontList. r=jdaggett. (73fb6b761) - Bug 1168299 - Break out style struct memory usage reporting from pres-shell. r=njn (aa29834de) - Bug 1182963 - Use nsTHashTable::Iterator in nsPresArena. r=njn (c4a24e5d7) - Bug 990974 - Slightly change how the caret clip works. r=roc Instead of looking at the caret's rect and determining whether we should clip it to the real content box clip or not at all, we just always clip it, but to a slightly bigger rect. In the cases that the caret was completely visible before, it'll still be completely visible with this change. However, in the cases that we did decide to clip before this patch, the result can be slightly different now: Before this patch, whenever the caret was partially clipped, it was partially clipped to the true content clip rect, but with this patch, the caret can be partially clipped to the slightly larger clip rect. (f62879687) - Bug 990974 - When using display ports, don't clip the painted contents to the content box clip. r=roc (26482c741) - Bug 990974 - Add a flag to ComputeFrameMetrics so that a different clip can be returned for the caret and non-caret content. r=roc (0d6027caa) - Bug 990974 - Give PaintedLayerDataTree a generic way of restricting a PaintedLayer to exactly one display item. r=roc (9f59f5bff) - Bug 990974 - Treat carets in async scrolled scrollframes differently from non-caret content. r=roc (ffdb9b629) - Bug 1141089 - Add more asserts for DisplayItemData, trying to catch whether we're accessing deleted instances. r=roc (e70921c98) - Bug 1178745 - Move some code around. r=roc (cd1ea1cf1) - Bug 1178745 - Respect scroll clips when flattening. r=roc (05621c6b7) - Bug 1073219 - Use a simple RAII struct instead of nsRefPtr to manage mLayerCount for MaskLayerImageKey. r=dholbert (eb78205ef) - Bug 1178745 - Add an nsIScrollableFrame API for getting the scroll clip. r=roc (a95a34deb) (1d0f42f44)

Well, jaclaz knows a lot about very few things and a little about lots of things. Compression is not one of the fields I know a lot about, but from the little I know the mslz format does not actually exist . It probably is one of the many LZ (Lempel Ziv) based compression formats used by MS, as such likely it can be made using compress, makecab, diamond or a similar oldish MS compressor. Try analyzing it with TriD: https://mark0.net/soft-trid-e.html maybe it finds a "better" name for the format. jaclaz .

Merged! https://github.com/mozilla/cubeb/pull/656#issuecomment-890597950

Fingers crossed. Honestly, unless they're hell-bent on flushing all memory of XP, I can't think of a good reason for why they wouldn't accept this fix. Let's hope Tobin won't have a heart attack if his so-called "MSFN hackers" manage to get official recognition. (Less name-calling, cussing, and paranoid lashing out at people who have been helping their project, and maybe they wouldn't need appeals like UXP development: it doesn't magically happen...) EDIT: If Tobin or someone else from PM reads this: sarcasm aside, I'm actually not saying this to fan the flames of conflict, the point is that it's painful to watch the upstream I believe most of us would ideally like to support and root for make that as hard as possible, and not just for MSFN members, but also a number of those in their own community.

PR submitted! https://github.com/mozilla/cubeb/pull/656

... This is Windows XP SPx you're still talking about , official Mozilla Firefox builds NEVER supported natively the h264 proprietary decoder in HTML5 video; the decoder is patented and its native inclusion in a browser requires the browser authors pay a "handsome" fee to the patent owners (the MPEG4 consortium). Google are rich enough to afford that fee, so Google Chrome comes bundled with that decoder (AVC=h264) and hence it's capable of native h264 playback under Windows XP... When Adobe Flash Player was around, it itself came with bundled h264/aac decoders (again, because Adobe are rich), so MP4 video streams could be played, via that plugin, even in browsers (like Firefox) without that decoder built-in (and XP users, like yourself, were "happy"...). When many video sites abandoned Flash and instead started using HTML5 embedded web players, the lack of h264 decoder in Firefox rose to the surface, again for Windows XP users ONLY... Your favourite OS is deficient in this sector because the vendor, Microsoft, did not equip it originally with that patented decoder, nor a provision was made to add it in a later stage via an update... You see, Mozilla, instead of paying the h264 patent fee, decided to shift the "issue" to the OS itself, so that Firefox could make use of the h264 decoder already present in the OS (as Microsoft had already paid that fee themselves); unfortunately for you, h264 dec is only present in Vista SP2+Platform-Update-Supplement and higher - the way for Firefox to use it is through Microsoft's WMF (Windows Media Foundation) framework, so you can't bring h264 support to Firefox under XP via installing Codec Packs (these are used for DirectX media players, like WMP). The Adobe Primetime CDM (content decryption module) came with a bundled h264 decoder (patent fee paid by Adobe) and as a side-effect (its primary purpose was DRM) it can be used as an HTML5 h264 decoder in versions of Firefox that supported the CDM (off the top of my head, I think it was v47.0-51.0 officially, but v52.0 also works) - again, this is solely for XP... Regarding Roytam1 browsers: New Moon 27 doesn't support h264 natively (on any OS), but you can "install" such support by downloading an additional "package" (lav), extracting it and placing some DLLs adjacent to "palemoon.exe". The UXP-based browsers, like New Moon 28 and Serpent 52, come with a special "kludge", i.e. h264 decoding support is included in the ffvpx third party library (for XP's sake only, the UXP-based browsers can still use WMF's native decoder, if on Vista SP2 and up...). Lastly, HTML5 video decoding in a browser under XP is S/W only, so the video watching performance you get depends, among other things, on the video codec selected to begin with and your CPU; some codecs are taxing your CPU more heavily than others; the higher the resolution/bitrate/framerate, the more your CPU suffers; performance of the youtube webpage alone (which is a literal beast of JS and CSS code currently) depends on the browser engine, CPU, GPU, available bandwidth, CDN you are served from, content blockers, etc. so, while I find these "stats-for-nerds" logs to be of some substance, they have little statistical weight when compared between different setups... The Adobe Primetime CDM requires SP3 for Windows XP... His "log" mentions the av01 video codec, aka av1/AOM, do note AOM != AVC, official Firefox ESR 52 never supported that codec; the codec is, however, supported in UXP browsers via a pref: media.av1.enabled;true but decoding taxes heavily your CPU... PS: @UCyborg 's post appeared in the middle of writing this , he's right, of course, but my post expands on what he kindly posted...

@mixit. Finally a fix, that's been a problem for a long time. I just tested it again in XP and the usual buffering was around 25:12. No reason for Mozilla not to have resolved it, there were plenty of complaints so they had to know. Probably too busy messing with the UI to be bothered with real bugs and then they wonder why their user base keeps dwindling.

For actual voice-chatting, Teamspeak 2 can be used too, even on Windows 98! Public servers worldwide exist, which can be connected to without much effort. The codecs of TS2 might sound a bit old fashioned though, but they are efficent.