popey456963

Google's Project Zero.

Why on Earth could they possibly feel it necessary to do this? The United States Patent Office doesn't have a complex system of sub-domains or even an EV license, if money were the object then they could just go with Let's Encrypt (not to mention the current license continues until 2018 anyway).

The amount of computing power it takes to encrypt with SSL is minimal, especially if you use some of the newer systems like ECDSA and should not be of concern to a company like the Patent Office.

It is Friday? Roughly 4PM on Friday, which means they'll likely be closing down shortly. Seems odd for them to do it as such a last minute thing.

You can source Li-ion/Li-Poly fairly easily (as a company, almost impossible as an individual) with 250 Wh/kg, I believe I read somewhere that Tesla hit about 260/270 with their latest power walls. Even so, I still have to doubt they'll reach more than 200km range with current technology.

Their mission is to release to the public in 2025 however, which makes the goal much more likely to be hit with improvements in technology.

It's the first point they mention on the landing page:

- 300 km range - Travel from London to Paris in one hour.

Imperial (A UK University) are currently making large leaps forward in terms of modelling a room or environment with just a single camera and little computing power. Their basic methodology was:

- Pick "unique" points currently in view

- Track how they move as the camera moves

- Combine this data with the accelerometer to get an accurate movement reading of the phone.

- You can get the depth of any point by comparing two images and knowing the change in user position.

Simple algorithm, but their results were astonishingly good. Snap don't need to model the entire room, they just need to work out where these points are to keep the image appearing still.

I'm sorry, what's CEF? I haven't come across that acronym before.

> Is this benchmark open source? I'd be really interested to try it compared to something similar build in Qt or Gtk+.

Afraid it's not, currently the only working copy is closed-source whilst I work on rewriting it all into an open source repository. Having said that, I'm in no doubt that Qt or Gtk+ would be significantly faster than rendering what is essentially a local website.

> I really hate to think how it'd cope on an embedded device with an ARM processor. There's a marked difference to me between Atom and e.g. Sublime Text.

Reminds me of a joke told by a friend of mine:

Friend: "The thing I like about Atom is that it encourages you to write small files."

Me: "How does it do that?"

Friend: "Well, it crashes if you write more than a couple hundred lines."

Personally, I too do use Sublime Text. Not entirely sure how Atom is so slow, but it takes ten times longer to startup and five times longer to search through my files. Definitely caused me to switch away from it.

> but the fact remains that the UI is built on the DOM with interactions handled by JS

Excellent point, but I think if you're doing complex interactions that require a large amount of computing time then you shouldn't be using a program like Electron. For something like a mail application, not much changes. We actually never remove mail items, simply hide them from view, so we have one large render time at start-up and then almost none after that (displaying and hiding an element from view is incredible efficient). For something like atom, you have a significant amount more happening and you want just about everything to be instantaneous. Plus the fact that it's expected to be able to deal with large files consistantly without any hiccups.

I swear Electron is incredibly fast in every instance I've used it. Unless you're doing heavy computation with complex algorithms, it's really nice. I don't believe VS Code has to do any computationally expensive computations, and it enables many more people to work on a project (JavaScript being a truly universal language).

I'm currently working on a Mail application and my benchmark test case is an email account with 20,000 emails to be displayed. Noting we currently have no lazy loading and all these are loaded from an on-disk database and put inside their own Shadow DOM it truly did surprise me when it took just over 400ms for an entire page load on my development laptop (~3 years old with an i5, nothing special).

Even if you need to do complex algorithms, just write that particular part in C and use it in the rest of your JS code like normal.

Considering how we're doing now? Yeah, I'm pretty cool with how they handled things.

Would you perhaps consider working together instead of on two separate projects? Half the workload for both of us to get the same final product!

Pretty sure most applications don't need to support RFC 2177 to still be efficient. Long-polling for most IMAP servers requires one packet every nine minutes (to the best of my knowledge), which is literally nothing. It would take months of being run constantly to even get up to a megabyte of data being transferred. Some rough back of the envelope calculations:

- 10 minutes per poll, 1440 minutes in a day, 144 packets per day.

- 50 bytes per packet, 1,000,000 bytes to a megabyte, 20,000 packets required.

- Roughly 140 days of time, or 5 months to reach a single megabyte.

Aren't there some optimisations that are so minuscule it isn't worth implementing them?