Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Re-writing history are we? (Score 1) 336

Prior to massive regulations insurance was affordable.

Um, that's if they're willing to sell it to you. I could not get insurance for epilepsy pre-ACA because the medications I needed were expensive, and also because people always called 911 after every seizure which meant routine ER visits, about two per month. Since insurers wanted to keep their insurance "affordable" for healthy dickheads trying to decide if they even needed it, that meant telling me GFY- which they did because there were no "massive regulations" preventing them.

Comment Re:Probably a minor oversight. Will likely be fixe (Score 4, Interesting) 221

It looks like its actually an underlying issue with Chromium, which is what powers Electron, the UI framework which VS Code is based on.

Simple CSS Keyframe Animation Causes Too High CPU Usage

Steps to reproduce the problem:
It happens on my Mac.

Demo page here:

Add a simplest keyframe animation to an element and Chrome will use 5-6x more CPU than it should.

e.g: .blinking { animation: 1s blink step-end infinite; }

@keyframes "blink" {
    from, to { visibility:hidden; }
    50% { visibility:visible; } }

What is the expected behavior?
CSS animation should consume equal (or close to equal) CPU load than its Javascript animation alternative.

Javascript setInterval consumes around 1.2% CPU on my Mac (Chrome's task manager)

1.2% for Javascript animation of a blinking cursor btw is the same usage that I get with no animation and the default cursor inside an input element.

CSS animation should produce the same results.

What went wrong?
CSS keyframe based animation consumes 7-8% CPU which is unjustified for such a simple case.

Comment Re:The actual real problem with Mars... (Score 1) 102

I never said they were one off rockets, I said they were custom built for specific launches, and that is correct - no launcher company has a stock from which they pull a rocket the week before a launch, the launch requirement comes well before the launch vehicle exists in any capable form, including the ICBM-conversions.

Comment Re:The actual real problem with Mars... (Score 0) 102

Since all launchers to date have been custom built for specific launches, where is the excess industrial capacity that is being used to launch Mars missions...? Which launch company is suddenly going "awww shucks, we have a spare rocket, anyone want to launch a Mars mission" or "we arent building anything next tuesday, anyone want a rocket for Mars"?

Comment Re:Makes Good Sense (Score 2) 87

The weight reduction from not having to carry the turbine portion of the engine (you still need to carry the fan part) is *massively* offset by the fact that you carry your "fuel" the entire distance of the trip, 100%. Current planes get more efficient the longer they fly, as they burn off their fuel they get lighter - replace that fuel with a storage system like batteries and your plane is going to weigh as much on landing as it did on takeoff, with no efficiency gains en route, so the energy needed will be constant throughout the flight.

And yes, this is still an issue on short haul flights.

Don't kid yourselves, batteries for powering aircraft is a non-starter, the economics simply dont work.

Comment With What? (Score 1) 94

AR with what? Phones? Maybe. Their desktops? Please. The GPUs in their desktops are garbage. Even the ones in the Mac Pros. I was a Mac user for ten years (sold my 2012 Mac Pro last month) and I I have always been disappointed by their choice of graphics chips.

Slashdot Top Deals

No extensible language will be universal. -- T. Cheatham