Sidnicious
Joined 17 years ago
Joined 17 years ago
- https://issues.chromium.org/issues/41359717
- https://bugzilla.mozilla.org/show_bug.cgi?id=1747999
macOS skipped compositing when only a single fullscreen surface with a black background was being rendered, but there were many ways for that render path to misbehave.
It only ever affected integrated graphics on dual GPU Macs, as far as I can remember.
It is so possible to preserve XSLT and other web features e.g. by wrapping them in built-in (potentially even standardized) polyfills, but that kind of work isn't incentivized over new features and big flashy refactors.
Six of them fit on the face of a dime, which is wild.
Another pattern is that you push buffers to the layer below you and there’s backpressure to keep you sending at the same rate they’re being played out. In that case you can just stop sending buffers when you have nothing to play.
Your reasons are correct. There are so many layers between an app (or web page) and the physical layer of sound which all burn power; phones and earbuds owe quite a bit of their battery life to shutting down bits of hardware when unused.
EDIT: this reminds me of a WWDC many years ago — Apple got really excited about timer coalescing and added parameters to all the low level timer APIs which let you indicate how much slop you want to allow for each individual timer. Ideally then the OS can keep the CPU asleep for longer and wake it up to do work in batches. Code that deals with real time sound has tight timing requirements and can’t be delayed as easily, so in a timer-coalesced world distinguishing between playing silence and playing nothing has an even bigger power impact.
Lack of backups is not a retention/deletion policy. Signal chats can, in fact, have a deletion policy set. Instead it directly ties retention to "how long can I last without losing or erasing my phone", which is not a useful proxy.
Anyone sufficiently motivated to keep messages forever can (a) set up the desktop client and back up its data store or (b) set up signal-cli and save everything that comes out of it.
No backups doesn't defeat this, it just makes life harder for everyone who relies on scrollback. Imagine if email worked this way.
A PDF doesn’t capture scrolling behavior, so a nested scrolling element will lose most of its content, and a page with a chat prompt or cookie notice might have part of its content covered.
A PDF won’t capture even simple interactive elements like image carousels, lightboxes, and collapsible sections, so content may be lost (“oops, I saved it on the second slide of the image carousel, but I really wanted the first one”).
As far as I know, a PDF won’t include embedded audio/video.
Many PDF exporters chunk the document into paper-sized pages (but, to be fair, some don’t).
Not sure if this tool nails all of those cases, but those are reasons why I’ve saved local copies of pages in the past.
In any case, both hardware and software keyloggers exist which would be thwarted by an onscreen keyboard. If I recall correctly, mouse keyboards became popular when keyloggers started being more known, and the following generation of malware took screenshots every time you clicked.
It’s a very obsolete security measure but did make sense briefly.
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool YES Chrome 99.0.4844.51:
- 1Password + µBlock Origin: 277 ± 2.9
- No extensions: 303 ± 5.1 (9% faster)
Safari 15.3:
- 1Password: 251 ± 2.6
- No extensions: 280.5 ± 2.6 (11% faster)Similarly, an SDF returns a number that represents how far a point in 3D space is from an object's surface. And, by calling that function strategically from a loop, you can draw a 3D scene using only that function.
previously: sdy@{google.com,chromium.org},sidney@{okcupid.com,keybase.io}
[ my public key: https://keybase.io/sidney; my proof: https://keybase.io/sidney/sigs/DJzkNxrS60U9aNarQjjhFWsTBZYcC_LFiMBtGmd67Cc ]