Open Thorin-Oakenpants opened 2 years ago
interesting perf
Of course nothing really happens in TZP until we receive all the JS files, at which point we start timing, but makes you wonder if trying to get most JS files under 14kb speeds up the initial loading - but wait, that's compressed .. check your network console
of course I expect creepy to simply wrap it's entire code into < 14kb, because, nerd!
I'm currently at 140kb and CSS is 157kb ๐ญ.
@abrahamjuliot OMG - https://bugzilla.mozilla.org/show_bug.cgi?id=1519167#c117 .. anba had to stop at part 99
well I got my 11.5 yr old PC down to ~210ms (including adding the webgl at around 15ms)
anyway, here's my new rig, current code
@abrahamjuliot ... I think I can get down to 50ms . what do you think?
Nice. Do we lose a lot of entropy with shorter font lists? Maybe that can be cut by half.
So I just removed a lot of fonts in windows, will check mac later on. I have a win11 desktop rig, with 182/186 fonts tested (everything MS provides incl win11, including all supplemental, and downloads such as 'Cascadia Code','Cascadia Mono') - I do not have 'Arial Unicode MS','MS Reference Specialty','MS Outlook' (which are installed with office or other MS products, IDK about office365) .. not looked at the new office font .. and I don;t have 'AlternateGothic2 BT'
which is in the RFP font vis level 1 for some reason (can't be assed looking up to re-read why jonathan added it, but it's not a MS font AFAICT, but it is in kBaseFonts). The 187th font is a poison pill
So .. I fixed some names up, and it's all peachy.
I had to remove anything that is a "variant" .. black, cond, light, demi, semi, whatever, ultra, etc - because they are not stable. I have an issue open for font variants. Remember when you said you had windows 10/11 sometimes detect Arial Black and sometimes now, or Arial Narrow .. whatever. Well, this seems to be due to some change in windows and/or Firefox. I believe it's due to the OS as FF is stable as fuck on my old machine.
unstable is like this
So I surmise this has to do with font-weight, and I think all I need to do is, in a new test or wrapped into this one, is break the fonts lists into weights and loop weights, list, font (and record base the same)
Anyway, so fonts dropped from 240 to 190 in windows. But I added an extra char (a tofu) in the test string. The shorter the test string the faster the test (less glyphs to get per font). So perf didn't change much. The font string used in the test doesn't increase detection of fonts, but it increases the bumber of sizes collected
if ("windows" === os) {
// Mล = 124 +"รก" = 125 +"ฮฉ" = 127 (win7)
// Mล - 141 +"รก" = 142 +"ฮฉ" = 144 | Mล - 141 +tofu = 154 | (win11: have 182/186 fonts
let tofu = get_fntCodes("tofu")
fntString = isTB ? "?-"+ tofu : "Mล"+ tofu
^ that's Mล
gave me 141 sizes for 182 fonts, but Mล
+tofu gave me 154 sizes for 182 fonts
now I have a mac, I'll be doing all that for mac. Linux and android font lists don't have any "variants"
I think fonts sizes may provide entropy (sort of an equivalency of system scaling, subpixels, cleartype, font version maybe), and I test them all because besides the core group they're all supplemental and you can't really leave any out - although I have, see code for why (assumptions, e.g if you have Segoe UI Variable Display
then you're going to have Segoe UI Variable Small
and Segoe UI Variable Text
and they are the same size, etc
With variants, there are so many (I and I will not be testing styles, e.g. italic), I may have to be more selective. But overall, it's up to me to cover as much as possible, or all of it .. so that when we do collect some data, we can see where the entropy is coming from. At least in FF116+ it's limited to Win10+ and macOS 10.16+ (or whatever it was)
perf
tofu: fonts: 3 ms | 50 ms | 5/21
unicode glyphs: fonts: 21 ms | 71 ms
fontsizes: fonts: 21 ms | 93 ms
Looks like it takes about 10 fonts per ms (there's a few ms in that 21 being used for base font sizes, and re-arranging the data into an object etc) .. so 18 or 19ms for 187 fonts. I think I'm going to be adding like 100 variants, so we're not going to save here, unless it's core expected fonts everyone has and data analysis says we don't lose entropy in measurements
I do have some ideas on how to speed up unicode measurements, maybe - but like fonts, that's an area I'm going to expand
๐น Pages I use to keep tabs on a few things
๐ฅ ToDo
๐ฉ perf
๐ฉ isVars
๐ฉ general: fingerprints, sections, lies
[click here]
's global FP.join()
.join()
on arrays for all sDetail data (where we can now use objects or arrays).join()
anywhere else unless we have to (or it is safe)typeof
where possible๐ฆ screen
vw
+wh
units, visualviewport etc see #29๐ฆ ua
harden oscpu: win7 vs win8/10 via tiny font checkharden userAgent from the other parts: i.e userAgent is constructed using a set methodbypass more parts of the userAgent than just version where possible๐ฆ feature detection
๐ฆ language
NumberFormat v3
1648137 + 1795756https://github.com/tc39/ecma402/pull/347
Intl.Segmenter
- 1423593, github, specTemporal
- 1519167, github, article, spec + cookbookIntl.LocaleInfo
- 1693576, githubIntl.Enumeration
- githubIntl.MessageFormat
- github๐ฆ storage
๐ฆ devices
radiusX/Y
,screenX/Y
,clientX/Y
๐ฆ svg
๐ฆ canvas
noise
fingerprint (just for toDataURL)๐ฆ webgl
1, 2, experimental
groups and subgroups e.g. affected byRFP/prefs
๐ฆ audio
DynamicsCompressorNode.reduction
- https://github.com/arkenfox/TZP/issues/67#issuecomment-857305813ac-outputLatency
is always0
even after two tries๐ฆ fonts
[click here]
)system-ui
1226042๐ฆ media
๐ฆ css
window.getComputedStyle(document.getElementsByTagName("body")[0]).backgroundColor
๐ฆ elements
๐ฆ misc
๐ซ BACKBURNER
and languagesections, results are not used anywherefont inflation
...