Where will we see the setting, and is it still rolling out? I can see in my old Gmail account where I have "Ask before displaying external images" selected, so I'm presumably protected from AMP for now, but I would've expected to see the setting for AMP alongside it.
Because the statement was one of fact, not opinion and therefore no correlation to ones' employer or experience as such.
If the statement was, "I think AMP for Email is perfectly fine as is and doesn't need an option to disable." that might be something to call for disclosure.
Does the person in question work on AMP for gmail? Also, I'm still uncertain that statements of fact (not opinion) necessitate disclosure in this case.
cramforce's position is quite Google-able (or DuckDuckGo-able). There are at least three other Googlers who work on AMP in this thread, and one other Googler who might or might not have AMP involvement (a DevRel). Only one discloses on their profile that fact, and none of them disclosed on their actual comments. They're not really hiding, mind you, and if you read a lot of corporatespeak, they stand out pretty well.
(toomuchtodo is indeed accurate that the Google Cloud team are top notch on disclosures.)
They can only hit a JSON endpoint in the same DNS zone (eTLD+1) as the sender's email, e.g. if the email is from sender@mail.example.com, it can only hit endpoints on example.com and its subdomains.
One important clarification since the question comes up often. AMP for email doesn't make emails inherently mutable.
Emails already support updating by including external image references inside the email. Allowing this is a choice of the client.
AMP for email makes JSON requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.
I doesn't have to connect. All email clients I use are set to block external content, unless I explicitly decide otherwise (but I can't remember when I last needed to see an image included in an HTML mail).
Emails already support updating by including external image references inside the email.
AMP for email makes json requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.
Looking at their technical steering committee, 3 out of 7 members are from Google, with only one from a company of what I would consider equivalent pull (Microsoft).
I would hardly consider Yahoo to be a leader in anything at this point, not sure about mail.ru. From an outsider's perspective AMP looks Google controlled.
It looks like from your comment history you are part of Google's AMP team. It would be nice to disclose that.
Yes, but you know, that isn't Google controlling it and these are all member from major internet companies that won't take part in such a "conspiracy".
Because we do the majority of the work. The governance body size will, however, expand with further non-Google members. So, the hypothetical "you just have to convince only one" is becoming less of an issue over time.
Of course it's always the benevolent Google ramming down their network down our throats. How would AMP bans work? You can't even read any email in any client?
Can you remind us again how AMP for email came to be?
I remember you talking about how transparent the process is, but, alas, you never described it. And to quote another member of the discussions back then, anyone raising concerns:
> were closed or locked, and the head of AMP blocked us.
You yourself stated to us that Gmail team would implement AMP4Email as they wished. Did Outlook or Yahoo or Mail.ru have a choice in just telling you not to deploy AMP4Email? Or did you tell them Gmail was doing it no matter what, and ask if they wanted to not lose compatibility with 2/3rds of all email accounts on the Internet?
Suggesting any part of AMP is open still feels very disingenuous when you recognize the monopoly position of the company spearheading it.
They can use a different TLD. One big benefit is that the literal TLD is in the list (not every domain) keeping the size of the list O(1) instead of O(n) as it is for other TLDs.
µMatrix blocks everything that's not from the primary domain unless I tell it otherwise, which is sometimes annoying, but on the other hand lets me cut out loads of crap (hello AMP-project).
Counter anecdote: As a Google engineer it always seemed like Edge implemented the sparsest possible version of the web platform to make major Google products work–and literally nothing else. That works to launch the browser, but then basically any product change runs a chance to no longer fall into that sparse subset and break in a browser. If Edge had implemented a more robust set of features, it would have massively improved compatibility down the road.
I highly suspect that the issue is that Windows video playback can only use scanout compositing if there is nothing on top of the video. Scanout compositing is significantly more energy-efficient than standard framebuffer compositing because it avoids a memory copy each frame.
This ultimately comes down to hardware limitations. GPUs are limited as to what they can compose during scanout, because of memory bandwidth limits. Each plane that you can alpha-blend together at scanout time multiplies the amount of memory fetches per dot you have to do. On today's high-DPI displays, the bandwidth going out to the display is very high to begin with, so you can't afford to multiply that by much. That is why putting something on top of a video is tricky: you're adding another layer to be alpha-blended on top, increasing your memory bandwidth by 50% over the two layers you already have (RGB for the background plus YUV for the video). The user's GPU may or may not support that--as I recall, prior to Skylake, Intel GPUs only had two hardware planes, for instance.
I'm not surprised that Microsoft just used "are there any DOM elements over the video?" as a quick heuristic to determine whether scanout compositing can be used. Remember that there is always a tradeoff between heuristics and performance. At the limit you could scan every pixel of each layer to see whether all of them are transparent and cull the layer if so, but that would be very expensive. You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.
> You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.
which, again, that's fine, but mayyyyybe they were a little lax in checking performance on nearly any other popular video site on the web to see if that heuristic is a good one?
Or maybe changing page layout in an extremely common way wasn't an effort to undermine a hyper specific benchmark?
I'd assume that it was actually an invisible, but not technically hidden div, leading to a fully transparent blending pass - divs with opacity:0 or display:none are trivial to optimize for this case.
On the other hand, pretty easy how such a div might trigger a less efficient path; if the video is top in the z-order then it can probably bypass being composited by the browser (and who knows, maybe even bypass being composited by the OS) and avoid a whole mess of rendering to a texture, texturing some triangles, and so on and so forth.
FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite).
> On the other hand, pretty easy how such a div might trigger a less efficient path
I mean, sure, you can always fall off the fast path, but given how common transparent divs over video are, the battery benchmark should have come with even more caveats. Edge is the most battery efficient browser†!
† for playing fullscreen video††
†† Battery test not valid if the page doesn't use the exact layout youtube used in December 2017. Also not valid if testing vimeo, or twitch, or any porn site, or...
> it's doing something that lacks any real reason but which hurts Edge.
In my own web development activities I can point to hundreds upon hundreds of hidden, invisible, and obscured DOM elements that have no obvious reason to for existing to someone outside the code-base where you find the commen explaining the required work around, browser hack, or legacy constraint. I've also experienced wildly divergent performance on MS browsers compared to others when creating content, often from something as trivial as DOM order or composition.
Clearly Google owes me some money for my part in their ongoing conspiracy to hurt Edge. I'm flexible, I'll accept GCE credit :)
> it's doing something that lacks any real reason but which hurts
Hey, there's a new div in the DOM, the only possible reason for a change like that is so Chrome can advertise about beating Edge on a benchmark nobody cares about? Even though they never beat Edge on it and this "advertising" never took place?
This was the credulity I was talking about. These events didn't happen (you literally wrote the stories plural! about edge winning the benchmark) and the motivations make no sense. I'm not sure why you'd repeat it without even a warning that it may just be a narrative made up from grumblings about fixing a fast path heard third hand.
I do care about video playback battery performance. So much so, in fact, that I bought my current laptop specifically so it would last long when watching videos.
Also note that tablets, smartphones, the Macbook Air and the Surface are sold on their battery stamina, and specifically while watching videos. And how would you measure that? Youtube, of course!
> And how would you measure that? Youtube, of course!
Makes total sense, but if you're over-fitting for Youtube's exact layout in 2016, you're eventually going to have to update your optimizations. Sites don't stay the same forever.
I fail to understand how an empty DIV can break a state-of-the-art video acceleration. Why not add another check to remove such empty HTML tags before hand.
> Why not add another check to remove such empty HTML tags before hand.
Sure, and they did. And then next month it’ll be something else, and a new check. The next month it’ll be something else yet again, and yet another check. Pretty soon Microsoft’s codebase is littered with checks and guards against the random things Google does, and they’ll still always be a deploy behind. Google could keep this up for years.
reply