izym

I don't think the same teams are working on video decoding and VR browsing.

That's a software implementation though. These new cards have actual hardware specifically for that.

When do you get in though?

It might introduce temporal artifacts, which would not be seen in stills.

Does this support Objective-C++? If not, do you have any plans to implement support for it?

In deferred rendering the cost of lighting is still dependent on the number of lights. In forward rendering it is dependent on both the number of lights as well as the scene geometry. You can apply various additional techniques to make each light much cheaper though.

You're not really being fair here. You could just as well distribute all needed dll's with the app. In fact, that's pretty much what Electron does.

> And C# is no slower than D.

I very much doubt that. Do you have anything to back up that statement?

How would WebAssembly ever do that?

Vægtafgift is not a thing anymore, there is only ejerafgift now.

Your CPU has 4 cores, but 8 threads due to Hyper-threading. It's quite normal that not all programs will benefit from the additional threads. It would be interesting to see how the compiler performs on more physical cores.

Scratchapixel has a lesson on it [1] which takes the same approach.

[1]: https://www.scratchapixel.com/lessons/3d-basic-rendering/ray...

Yes, but on the other hand rasterization is implemented in hardware on GPUs which gives it a great performance advantage. Also, sorting before rasterizing allows most triangles to be discarded before any fragments are created. Besides, creating and traversing an acceleration structure does definitely not make ray tracing free. Especially traversal is not exactly cache-friendly. Also, rays passing closely by geometry, but not hitting it, will traverse rather deep into the tree and then backtrack, which is rather costly. Another advantage of rasterization is that it is data-parallel at the vertex level. The disadvantage is that it is far less flexible in what you can render compared to ray tracing; it's only really practical for camera rays.

> raytracing an image takes much longer than the polygon-based rendering done by most game engines.

Minor nitpick, but it has nothing to do with the fact that it renders polygons. Ray tracing can also render polygons. More precisely, game engines use rasterization which works by projecting triangles onto the screen rather than tracing rays through the screen.

That's not going to work for e.g. a table that is part of your content.

I can't remember if threading support is in yet, but it should be possible. The downside is that it will be a rather hefty binary the user has to download.

Indeed, the article does not represent the 2016 sales at all. Tesla sold 176 cars in 2016 in Denmark and 2738 in 2015 [0]. While there is definitely a drop, the sales of 2015 were probably also boosted by the fact that lots of Danes, who were interested in buying a Tesla, made sure to do so before the law took effect. In 2014 they sold 460.

[0]: http://www.bilimp.dk/statistics/index.asp

What do you mean by "considering these workloads"? It sounds like a fairly light workload.

Mendeley. Not the nicest UX, but it syncs, has tags relevant for academic papers and can export everything as a bibtex file.

VW's newer interfaces are also quite lag-free. But then again, it is the same concern as Audi, so I guess it makes sense.

Yes, people are quite aware of that, and if you check the comments you'll see points made against it. Also, ? is very much language level.

Well, they did, in a very non-buzzwordy manner.

I asked you to provide a single example as proof and you have not done so. There is no pissing contest in asking you to provide a tiny bit of proof for your statements.

You didn't answer my question :)

When have they broken stuff post 1.0?

Nontrivial games take time to make.

Very good points, but you should try to keep a more civil tone.

Yes, but forking on GitHub means that initially it will be just their software.

> Breaking the behavior of my back button is one of the worst user experiences I get these days. Usually it makes me so angry that I just leave the site right away.

Obviously that is not the wanted user experience. Disregarding SPAs as a solution because of an unintended behaviour is kind of throwing the baby out with the bath water.

> Browsers can do that on their own since forever, given a carefully crafted HTML page.

How are you rendering parts of something from a server before receiving anything from the server using only HTML? I'm talking about the following flow:

1. User clicks link

2. Instantly the layout etc. is rendering using JS, with fancy loading elements (maybe ala how FB does their news feed) for the missing items

3. The data is loaded and put into the layout

Whereas for the non-SPA flow the user would have to wait for data to be received before anything is rendered. Of course pre-fetching alleviates this a bit, but it still requires the whole page to re-render.

> The 1ms is network overhead, witch is nothing considering how long it takes for the image to render on the screen.

Yes, latency for a single bit of payload to ever hit the client. The rest of the data then needs to be transferred as well. Transferring that amount of data constantly would be terrible with regards to battery life.

> The CPU and the GPU could be several miles apart.

How exactly? Would you send draw commands over the internet?