http://getgems.org

Code is here: https://www.dropbox.com/s/jx8kvy7jw4lxtwi/style.css?dl=0

Here is a demo/preview of the changes:

I welcome Vitaliy or other people to improve on these changes, I don't need any credit.

Until now, HUD displays in cars looked like text sitting on the windscreen. Now it appears to float in front of the car.

The head-up display, which Mercedes-Benz is introducing into its first vehicle model as of 2014, takes this to a higher level. The system provides data on vehicle speed and speed limits, and issues navigation instructions and warnings from assistance systems. The ‘head-up display’ supplements the information in the instrument cluster. As in modern day aircraft, important information is reflected onto the windshield, directly in the driver’s field of vision, ensuring drivers are less distracted away from what is happening on the road ahead. Furthermore, the eyes do not have to adjust between distance vision and short-range vision, because the information seems to hover above the engine hood some two meters in front where drivers can absorb it without having to avert their gaze or make optical corrections.

Perhaps with similar but wearable technology (a la Google Glass), city streets will no longer be filled with pedestrians looking down at their phones?

http://technicity.daimler.com/en/hud-en/

MediaTek is the first adopter of a true, authentic octa-core SoC in a mobiles device, while leveraging its benefits and optimizing the system approach to the absolute maximum.

Unlike existing octa-core solutions in the market, which can only activate half of their CPU cores at onceMediaTek True Octa-Core allows for all eight of its cores to run simultaneously, offering the ultimate combination of performance and power-efficiency.

• Advanced web browsing: With the unique ability to allocate individual browser tabs to CPU cores, MediaTek True Octa-Core allows for a faster, more stable web browsing experiences.
• Smoother user interfaces: With the ability to delegate user inputs to individual cores and render 3D effects more smoothly, the functionality and appearance of user interfaces in both applications and operating systems are significantly enhanced.
• Superior gaming experiences: The advanced multi-threaded programming deployed in the MediaTek True Octa-Core, enables different sequences to be allocated to different cores, delivering enhanced video frame-rate processing and exceptionally low-latency gaming experiences.
• Efficient video playback: When on decoding mode, the battery used for decoding HEVC (H.265) FHD video can be reduced by up to 18 percent compared to current quad-core solutions. While on display mode, MediaTek True Octa-Core provides users 20 percent more frames.

Via: http://www.mediatek.com/en/Event/201307_TrueOctaCore/tureOcta.php

Check also http://www.mediatek.com/_en/Event/201307_TrueOctaCore/MediaTekTrueOcta-CorePositionPaper.pdf

http://www.indiegogo.com/projects/tango-super-pc-worlds-most-powerful-pocketable-gameable-officeable-pc

If you are wondering how much faster is my CPU-bound function in native code instead of Nitro JS, the answer is about 5x faster. This result is roughly consistent with the Benchmarks Game's results with x86/GCC/V8.

But a factor of 5 is okay on x86, because x86 is ten times faster than ARM just to start with.  You have a lot of headroom. The solution is obviously just to make ARM 10x faster, so it is competitive with x86, and then we can get desktop JS performance without doing any work!

Whether or not this works out kind of hinges on your faith in Moore's Law in the face of trying to power a chip on a 3-ounce battery.  I am not a hardware engineer, but I once worked for a major semiconductor company, and the people there tell me that these days performance is mostly a function of your process.   The iPhone 5's impressive performance is due in no small part to a process shrink from 45nm to 32nm; a reduction of about a third.  But to do it again, Apple would have to shrink to a 22nm process.

Just for reference, Intel's Bay Trail, the x86 Atom version of 22nm, doesn't currently exist.  And Intel had to invent a whole new kind of transistor since the ordinary kind doesn't work at 22nm scale.  Think they'll license it to ARM?  Think again. There are only a handful of 22nm fabs that people are even seriously thinking about building in the world, and most of them are controlled by Intel. In fact, ARM seems on track to do a 28nm process shrink in the next year or so (watch the A7), and meanwhile Intel is on track to do 22nm and maybe even 20nm just a little further out.  On purely a hardware level, it seems much more likely to me that an x86 chip with x86-class performance will be put in a smartphone long before an ARM chip with x86-class performance can be shrunk.

In fact, mobile CPUs is currently hitting the same type of limit that desktop CPUs hit when they reached ~3GHz : Increasing clock speed further is not feasible without increasing power a lot, same will be true for next process nodes although they should be able to increase IPC a bit (10-20% maybe). When they faced that limit, desktop CPUs started to become dual and quad cores, but mobile SoC are already dual and quad so there is no easy boost. So Moore's Law might be right after all, but it is right in a way that would require the entire mobile ecosystem to transition to x86.

Here is where a lot of competent software engineers stumble.  The thought process goes like this - JavaScript has gotten faster!  It will continue to get faster!

The first part is true.  JavaScript has gotten a lot faster.  But we are now at Peak JavaScript.  It doesn't get much faster from here. Why?  Well the first part is that most of the improvements to JavaScript over its history have actually been of the hardware sort.  

What about JITs though?  V8, Nitro/SFX, TraceMonkey/IonMonkey, Chakra, and the rest?  Well, they were kind of a big deal when they came out, although not as big of a deal as you might think.  V8 was released in September 2008.  The performance between Chrome 8 and Chrome 26 is a flatline, because nothing terribly important has happened since 2008.   The other browser vendors have caught up;some slower, some faster;but nobody has really improved the speed of actual CPU code since

Ream more at http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Certainly, this sensor is not large enough to make low-light or "shallow DOF" shooters happy, and mobile phones are not really expected to have decent lenses mounted. But the reason why I wanted to mention this product announcement here, anyway, is that I found 2012 to be a somewhat sad year regarding the video capabilities of new enthusiast cameras. It seems to me that companies like Canon, Minolta, Olympus, Sony etc. want us to actually believe that it is still rocket science to read out sensors quickly and do the post-processing required to record videos from that - while in reality, they just deprive their mid-range cameras of even 1080p60 modes to justify their "pro camcorder" pricings.

2012 was the year that mobile phones took the lead regarding maximum still image resolution (Nokia 808 - see http://www.technobuffalo.com/mobile-devices/phones/why-the-nokia-808-pureview-is-the-first-real-threat-to-the-digital-camera/ ), however reasonable that may be. 2013 will be the year that mobile phone shooters will smile at those dinosaur below-4k-video-camera owners - whatever shortcomings their recordings will have due to the mobile phone form factor restrictions.

Don't get me wrong, I will certainly not trade in my GH2 for a mobile phone. But I'm somewhat frustrated how easily the camera manufacturers give up their market share to mobile phone manufacturers all for the wrong reasons. A child that grew up owning a mobile phone that - at least on paper - has better specs than any non-bulky dedicated camera will be a lost cause for the camera industry.

I'm located in southern part of Sweden But i can post this worldwide, payment via PayPal. European-Union citizens won't pay eventual taxes/customs.