bfgeek · HackerTrans

4 เดือนที่ผ่านมาdiscuss

One has to wonder if this due to the global memory shortage. ("Oh - changing our memory allocator to be more efficient will yield $XXM dollar savings over the next year").

bfgeek

6 เดือนที่ผ่านมาdiscuss

HTML parsing supports some of this, e.g:

  text <b>bold <i>bold-italic</b> italic</i>

bfgeek

7 เดือนที่ผ่านมาdiscuss

We found it was roughly on par performance wise for simple text (latin), and faster for more complex scripts (thai, hindi, etc). It also is more correct when there is kerning across spaces, hyphenation, etc.

For the word-by-word approach to be performant you need a cache for each word you encounter. The shape-by-paragraph approach we found was faster for cold-start (e.g. the first time you visit a webpage). But this is also more difficult to show in standard benchmarks as benchmarks typically reuse the same renderer process.

bfgeek

7 เดือนที่ผ่านมาdiscuss

Blink's (Chromium) text layout engine works the following way.

1. Layout the entire paragraph of text as a single line.

2. If this doesn't fit into the available width, bisect to the nearest line-break opportunity which might fit.

3. Reshape the text up until this line-break opportunity.

4. If it fits great! If not goto 2.

This converges as it always steps backwards, and avoids the contradictory situations.

Harfbuzz also provides points along the section of text which is safe to reuse, so reshaping typically involes only a small portion of text at the end of the line, if any. https://github.com/harfbuzz/harfbuzz/issues/224

This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.

bfgeek

7 เดือนที่ผ่านมาdiscuss

You can exploit flexbox for this type of layout: https://bfgeek.com/flexbox-image-gallery/

bfgeek

9 เดือนที่ผ่านมาdiscuss

> "At this point, the engineers in Australia decided that a brute-force approach to their safe problem was warranted and applied a power drill to the task. An hour later, the safe was open—but even the newly retrieved cards triggered the same error message."

What happened here (from what I recall) was far funnier than this does it credit.

The SREs first attempted to use a mallet (hammer) on the safe (which they had to first buy from the local hardware store - don't worry it got expensed later), then after multiple rounds of "persuasion" they eventually called in a professional (aka. a locksmith) who used a drill+crowbar to finally liberate the keycard.

The postmortem had fun step by step photos of the safe in various stages of disassembly.

bfgeek

10 เดือนที่ผ่านมาdiscuss

One thing to keep in mind when developing these large lists of fonts is that they are generally terrible for performance if the appropriate glyphs for what you are trying to display aren't present in the first font (and the font is available - this isn't an issue if the font isn't available at all).

This is generally more of an issue with non-latin scripts (or when emoji is present for example), and developers adding a font which doesn't have glyph coverage - or sparse glyph coverage.

Chrome/Firefox devtools both have a section "Rendered Fonts"/"Used Fonts" which show which gylphs are used from which font.

Additionally if you are showing non-latin, make sure to language tag your markup: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

`font-family: sans-serif` if not language tagged with incur a similar fallback perfromance penalty (the browser will have to change the "english" sans-serif font, find no glyphs, then use the "other-lang" sans-serfic font).

bfgeek

11 เดือนที่ผ่านมาdiscuss

> which are more powerful and is out-of-spec

These are in the specification here: https://drafts.fxtf.org/filter-effects-1/#typedef-filter-url

And used by backdrop-filter here: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProp...

bfgeek

11 เดือนที่ผ่านมาdiscuss

My biggest pet peeve is designers using high end apple displays.

You've average consumer is using a ultra cheap LCD panel that has no where near the contrast ratio that you are designing your mocks on, all of your subtle tints get saturated out.

This is similar to good audio engineers back in the day wiring up a dirt cheap car speaker to mix albums.

bfgeek

ปีที่แล้วdiscuss

This likely more effective quite a few years ago, but not particularly important today.

Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes.

"overflow: clip" is also much more lightweight than "overflow: hidden"

bfgeek

ปีที่แล้วdiscuss

Part of the design constraint here is to reuse the existing properties that exist for multi-column layout which have existed for a long time - https://developer.mozilla.org/en-US/docs/Web/CSS/column-rule

This proposal extends this mechanism to be more general.

bfgeek

ปีที่แล้วdiscuss

Yeah - this was arguably mostly my fault (sorry!).

There's quite a bit of history here, but the abbreviated version is that the dialog element was originally added as a replacement for window.alert(), and there were a libraries polyfilling dialog and being surprisingly widely used.

The mechanism which dialog was originally positioned was relatively complex, and slightly hacky (magic values for the insets).

Changing the behaviour basically meant that we had to add "overflow:auto", and some form of "max-height"/"max-width" to ensure that the content within the dialog was actually reachable.

The better solution to this was to add "max-height:stretch", "max-width:stretch". You can see the discussion for this here: https://github.com/whatwg/html/pull/5936#discussion_r5136422...

The problem is that no browser had (and still has) shipped the "stretch" keyword. (Blink likely will "soon" - https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2n... )

However this was pushed back against as this had to go in a specification - and nobody implemented it ("-webit-fill-available" would have been an acceptable substitute in Blink but other browsers didn't have this working the same yet).

Hence the calc() variant. (Primarily because of "box-sizing:content-box" being the default, and pre-existing border/padding styles on dialog that we didn't want to touch).

One thing to keep in mind is that any changes that changes web behaviour is under some time pressure. If you leave something too long, sites will start relying on the previous behaviour - so it would have been arguably worse not to have done anything.

It may still be possible to change to the stretch variant, however likely some sites are relying on the extra "space" around dialogs now, and would be mad if we changed it again. This might still be a net-positive however given how much this confuses web-developers (future looking cost), vs. the pain (cost) of breaking existing sites.

Sorry!

bfgeek

ปีที่แล้วdiscuss

The point I was after to make is that you can't assume that road wear scales the same way as tyre wear (I was assuming same material fwiw, just different loads). They are being worn under very different modes/scenarios.

bfgeek

ปีที่แล้วdiscuss

> I think as a starting point, I would expect that tire wear should remain roughly in proportion to road wear

IMO this would be a suspect assumption to make w/o data to back it up. You've got two dissimilar materials interacting (in very different modes). E.g. rolling a metal ball bearing on a wood surface would obviously cause the wood to degrade far more than the ball bearing, (and even a wooden ball rolling on a wood surface would wear substantially less due to the mode difference).

(If I had to guess the road has a higher wear as the surface has a tensile stress around the contact patch of the tyre, causing most of the damage, but this is just armchair engineering at this stage).

bfgeek

ปีที่แล้วdiscuss

To add to this, (from what I remember reading the study at the time) it was basically racing a car around a track (think lots of tyre squealing around corners), and found that the tyre wear was very high. I haven't seen a study which actually simulates somewhat "normal" driving (presumably because the wear is so low driving like that it's difficult to measure). Also didn't factor in a bunch of different stuff - tyres are effected by lots of things; compound, temperature, pressure, surface abrasion, etc. There might be an effect! But this study was very bad.

bfgeek

2 ปีที่แล้วdiscuss

You can create a new thread via. `new Worker` but using a worker requires a separate file, and lots of serialisation code as you communicate via `postMessage`. TC39 module expressions helps but not a lot of movement recently. https://github.com/tc39/proposal-module-expressions?tab=read...

bfgeek

2 ปีที่แล้วdiscuss

A fun simple gear related concept is "hunting tooth".

https://en.wikipedia.org/wiki/Gear_train#Hunting_and_non-hun...

Basically you don't want any common denominators in teeth count, otherwise the same sets of teeth will engage at some frequency. If there is a small imperfection on a tooth it'll wear out quicker. E.g. a set with 5:14 teeth will theoretically wear better than a set with 5:15 teeth.

bfgeek

2 ปีที่แล้วdiscuss

It depends on the project, but most large scale projects require test(s) for the fix, and will block submission unless its provided.

These types of projects undergo constant code-change/refactoring/re-architecture etc. If you don't add a test for your specific issue, there is a non-trivial change that it'd be broken again in some future release.

Its somewhat worse if an issue gets fixed, and broken again, vs. it being broken the whole time. E.g. with the former users have likely started to rely on the fixed behaviour, then will experience disruption when it breaks again.

bfgeek

2 ปีที่แล้วdiscuss

These names come from the html spec: https://html.spec.whatwg.org/#workerglobalscope https://html.spec.whatwg.org/#workletglobalscope

Chromium (and most other browser engines) will use the specification names for things like this. E.g. equivalent code in WebKit, and Gecko: https://github.com/WebKit/WebKit/blob/80c1e6d05e4679c08e3a6e... https://searchfox.org/mozilla-central/source/dom/worklet/Wor...

bfgeek

2 ปีที่แล้วdiscuss

If you have something like:

  columns: 1fr auto max-content

  <!-- items -->
  <div>1</div>
  <div>somethingsuperlong</div>
  <div style="span: 2;">something else</div>

You first need to decide how big each of the three columns are going to be, then you want to place the items in each of the columns.

Depending on the non-fixed column type (there are different rules for each type) you want to ensure their constraints are satified (typeically they are big enough to encompass the items).

comments