mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Air Mozilla: Bored and Brilliant: Finding Digital Equilibrium, with Manoush Zomorodi

Mozilla planet - ti, 13/02/2018 - 19:00

 Finding Digital Equilibrium, with Manoush Zomorodi “Doing nothing” is vital in an age of constant notifications and digital distractions. Manoush consulted with neuroscientists and cognitive psychologists about the possibilities of “mind...

Categorieën: Mozilla-nl planet

Mozilla GFX: WebRender newsletter #14

Mozilla planet - ti, 13/02/2018 - 13:05

Your favorite WebRender newsletter is ready. TL;DR: “fixed […], fixed […], fixed […], Glenn makes things even faster, fixed […], ad-lib”. Still mostly focusing on conformance and stability, although there is some performance work in progress as well.

Without further ado:

Notable WebRender changes
  • Glenn impemented mip-mapping to get high quality down-sampling of large images.
  • Marting cleaned some code up.
  • Martin made some changes to how clip ids are assigned in order to make it possible to reduce the amount of hashing we do and improve performance.
  • Glenn wrote the initial implementation of an image brush shader which allows us to segment some images and improve performance in common cases (when there’s no tiling, spacing and repetition).
  • Lee improved the precision of text shadow with sub-pixel anti-aliasing.
  • Martin improved something about how hit testing and clipping interact (I don’t quite understand the ins and outs of this but it fixed a hit testing issue).
  • Glenn avoided requesting images from the texture cache if they are already present in the pre-render cache (saves wasted work and memory).
  • Kats fixed an issue in the yaml serializer.
  • Lee implemented passing variation dictionaries on CTF font creation.
  • Kvark updated wrench and the sample apps to use an up to date version of glutin instead of an old fork.
  • Glenn implemented partial rendering of off-screen pictures and render tasks.
  • Glenn fixed z-ordering of transformed content inside preserve-3d contexts.
  • Martin made hit testing consistent between frames.
  • Kats avoided rendering frames that are generated only for hit testing.
  • Nical implemented tracking removed pipelines to facilitate managing externally owned memory.
  • eeejay implemented color matrix filters, useful for accessibility and SVG color matrix filters.
Notable Gecko changes
  • Jeff and Gankro enabled blob images by default.
  • Kats enabled WebRender hit testing by default, and it fixed a whole lot of bugs.
  • Lee worked around a sub-pixel glyph positioning issue.
  • Sotaro fixed an issue with windowed plugins such as flash.
  • Sotaro tweaked the swap chain type on Windows, and then fixed an issue with this specific configuration not allowing us to do a graceful compositor fallback when the driver fails.
  • Heftig fixed some text being rendered with the wrong metrics with some OpenType font collections by making sure we pass the proper face index to WebRender.
  • Jamie removed a limitation on the size of recording DrawTargets we use with blob images.
  • Gankro fixed a very bad rendering corruption by ensuring we make the right context current before rendering.
  • Andrew improved the way shared memory is handled to avoid creating many file descriptors (and void running into the limit).
  • Kats fixed a deadlock in the APZ code.
  • Kvark fixed a crash with the capture debugging tool, and another one.
  • Kvark automated including WebRender’s revision hash in the generated captures.
  • Kats fixed an assertion happening when transaction ids don’t increase monotonically (can happen when we reuse a pres context from the back-forward cache).
  • Martin fixed a bug in the way scroll ids are assigned and handled when building the display list for the root scroll frame.
  • Emilio fixed a memory leak.
  • Kats fixed an issue in the frame throttling logic which was messing with hit-testing.
  • Kats auditted the reftests and marked new tests as passing.
  • Lee ensured the ClearType usage setting isn’t ignored when WebRender is enabled.
  • Sotaro fixed a memory leak.
Enabling WebRender in Firefox Nightly

In about:config, just set “gfx.webrender.all” to true and restart the browser.

Note that WebRender can only be enabled in Firefox Nightly.

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 221

Mozilla planet - ti, 13/02/2018 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community News & Blog Posts Crate of the Week

This week sadly had to go without a crate for lack of votes.

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

117 pull requests were merged in the last week

New Contributors
  • bobtwinkles
  • Martin Algesten
  • Peter Hrvola
  • Yury Delendik
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

The community team is trying to improve outreach to meetup organisers. Please fill out their call for contact info if you are running or used to run a meetup.

If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access.

Rust Jobs

No jobs listed for this week.

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

No quote was selected for QotW.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42 and llogiq.

Categorieën: Mozilla-nl planet

Michael Comella: Gmail Per-label Notifications for FastMail

Mozilla planet - ti, 13/02/2018 - 01:00

As someone who tries not to check their email often, I’ve relied on the Gmail Android app to notify me when urgent emails arrive. To do this, I:

  1. Use Gmail filters (through the web interface) to add a label to important messages: notify me
  2. Enable notifications in the Gmail app (Settings -> me@gmail.com -> Notifications)
  3. Disable any “Label notifications” enabled by default (e.g. Inbox; Settings -> me@gmail.com -> Manage labels -> Inbox -> Label notifications)
  4. Enable “label notifications” for notify me

Now I’ll receive notifications on my Android phone for urgent emails, labeled notify me, but not for other emails - great!

FastMail

I recently switched to FastMail, which does not support notifications on a per-folder basis (folders stand in for labels), so I needed a new solution. I found one in FastMail’s Sieve Notify extension.

FastMail uses the Sieve programming language to filter incoming emails. When a user uses the Rules GUI to create these filters, FastMail will generate the necessary Sieve scripts used behind the scenes. However, the GUI is limited so they allow users to write custom sieve code to filter mail in advanced ways.

Their Sieve implementation comes with many extensions, one of which is the Notify extension. Notify, when called from a Sieve script, can launch a notification from the FastMail mobile app with the user-specified custom text. Note that Notify can also be used to forward an email or send a message through twilio, Slack, or IFTTT.

Here are the basic steps to get Notify working:

  1. Write a custom Sieve script (through the web interface) to run Notify on desired emails (Settings -> Rules -> Edit custom sieve code; there will also be auto-generated Sieve code here)
  2. Disable notifications (yes disable!) in the FastMail app: this stops notifications for mail that isn’t using Notify (Device Settings -> Notifications)

Here’s an example Sieve script to open a notification for mail from a@b.com or x@y.xyz, keep the message, and stop futher filtering:

if anyof( address :is "From" "a@b.com", address :is "From" "x@y.xyz" ) { # Notify the app with the specified text notify :method "app" :options ["From","Full"] :message "$from$ / $subject$ / $text[500]$"; # Keep the message and don't go through additional filters. # Without "keep", "stop" will discard the message so be careful! keep; stop; }

See additional details at the Notify documentation here. I paste this script in the bottom-most custom sieve section (below the rules generated from the Organize Rules GUI) though it could be moved anywhere. Once the script is added and notifications are disabled, the FastMail app will send notifications if and only if they match the Notify filters!

This solution comes with some pros:

  • Unlike the alternative solution below, notifications are independent of folders so all mail can end up in the Inbox
  • In theory, it will work automatically when switching between iOS and Android

And cons (on Android, at least):

  • Each email will create a new notification: they don’t batch together
  • Clicking on a notification does not launch the app: it must be opened from the launcher
  • The notifications have no quick actions (e.g. reply, archive, delete)
  • With my Sieve order, other filters will take precedence and may prevent Notify from running. This can be fixed.
An alternative solution

Before finding this solution, I first came up with another: I installed a local mail client that could enable/disable notifications at the folder level (K-9 Mail) and mimicked the Gmail app solution. This was unsatisfactory to me because it required me to check two folders for my new mail - Inbox and notify me - since a FastMail message can only exist in one folder, unlike Gmail labels. This solution also forced me to configure an unfamiliar client (K-9 isn’t simple…) and to trust it with login credentials.

Categorieën: Mozilla-nl planet

Mozilla Security Blog: Restricting AppCache to Secure Contexts

Mozilla planet - mo, 12/02/2018 - 23:54

The Application Cache (AppCache) interface provides a caching mechanism that allows websites to run offline. Using this API, developers can specify resources that the browser should cache and make available to users offline. Unfortunately, AppCache has limitations in revalidating its cache, which allows attackers to trick the browser into never revalidate the cache by setting a manifest to a malformed cache file. Removing AppCache over HTTP connections removes the risk that users could see stale cached content that came from a malicious connection indefinitely.

Consider the following attack scenario: A user logs onto a coffee shop WiFi where an attacker can manipulate the WiFi that is served over HTTP. Even if the user only visits one HTTP page over the WiFi, the attacker can plant many insecure iframes using AppCache which allows the attacker to rig the cache with malicious content manipulating all of those sites indefinitely. Even a cautious user who decides only to login to their websites at home is at risk due to this stale cache.

In line with our previous stated intents of deprecating HTTP and requiring HTTPS for all new APIs, we are continuing to remove features from sites served over insecure connections. This means that websites wishing to preserve all their functionality should transition their sites to using TLS encryption as soon as possible.

In Firefox 60+ Beta and Nightly, Application Cache access from HTTP pages is denied. Starting with Firefox 62 Release, Application Cache over HTTP will be fully removed for all release channels. All other browsers have also stated their intent to remove: Chrome, Edge, WebKit. This change will also be reflected in the HTML standard.

Going forward, Firefox will deprecate more APIs over insecure connections in an attempt to increase adoption of HTTPS and improve the safety of the internet as a whole.

The post Restricting AppCache to Secure Contexts appeared first on Mozilla Security Blog.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Update: Mozilla Will Re-File Suit Against FCC to Protect Net Neutrality

Mozilla planet - mo, 12/02/2018 - 22:49

Protecting net neutrality is core to the internet and crucial for people’s jobs and everyday lives. It is imperative that all internet traffic be treated equally, without discrimination against content or type of traffic — that’s the how the internet was built and what has made it one of the greatest inventions of all time.

What happened?

Last month, Mozilla filed a petition against the Federal Communications Commission for its disappointing decision to overturn the 2015 Open Internet Order because we believe it violates federal law and harms internet users and innovators.

We said that we believed the filing date should be later (while the timing seemed clear in the December 2017 draft order from the FCC, federal law is more ambiguous). We urged the FCC to determine the later date was appropriate, but we filed on January 16 because we are not taking any chances with an issue of this importance.

On Friday, the FCC filed to dismiss this suit and require us to refile after the order has been published in the Federal Register, as we had anticipated.

What’s next?

We will always fight to protect the open internet and will continue to challenge the FCC’s decision to destroy net neutrality in the courts, in Congress, and with our allies and internet users.

The FCC’s decision to destroy net neutrality rules is the result of broken processes, broken politics, and broken policies. It will end the internet as we know it, harm internet users and small businesses, erode free speech, competition, innovation and user choice in the process. In fact, it really only benefits large Internet Service Providers.

We will re-file our suit against the FCC at the appropriate time (10 days after the order is published in the Federal Register).

What can you do?

You can call your elected officials and urge them to support net neutrality and an open internet. Net neutrality is not a partisan or U.S. issue and the decision to remove protections for net neutrality is the result of broken processes, broken politics, and broken policies. We need politicians to decide to protect users and innovation online rather than increase the power of a few large ISPs.

The post Update: Mozilla Will Re-File Suit Against FCC to Protect Net Neutrality appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Update: Mozilla Will Re-File Suit Against FCC to Protect Net Neutrality

Mozilla Blog - mo, 12/02/2018 - 22:49

Protecting net neutrality is core to the internet and crucial for people’s jobs and everyday lives. It is imperative that all internet traffic be treated equally, without discrimination against content or type of traffic — that’s the how the internet was built and what has made it one of the greatest inventions of all time.

What happened?

Last month, Mozilla filed a petition against the Federal Communications Commission for its disappointing decision to overturn the 2015 Open Internet Order because we believe it violates federal law and harms internet users and innovators.

We said that we believed the filing date should be later (while the timing seemed clear in the December 2017 draft order from the FCC, federal law is more ambiguous). We urged the FCC to determine the later date was appropriate, but we filed on January 16 because we are not taking any chances with an issue of this importance.

On Friday, the FCC filed to dismiss this suit and require us to refile after the order has been published in the Federal Register, as we had anticipated.

What’s next?

We will always fight to protect the open internet and will continue to challenge the FCC’s decision to destroy net neutrality in the courts, in Congress, and with our allies and internet users.

The FCC’s decision to destroy net neutrality rules is the result of broken processes, broken politics, and broken policies. It will end the internet as we know it, harm internet users and small businesses, erode free speech, competition, innovation and user choice in the process. In fact, it really only benefits large Internet Service Providers.

We will re-file our suit against the FCC at the appropriate time (10 days after the order is published in the Federal Register).

What can you do?

You can call your elected officials and urge them to support net neutrality and an open internet. Net neutrality is not a partisan or U.S. issue and the decision to remove protections for net neutrality is the result of broken processes, broken politics, and broken policies. We need politicians to decide to protect users and innovation online rather than increase the power of a few large ISPs.

The post Update: Mozilla Will Re-File Suit Against FCC to Protect Net Neutrality appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

K Lars Lohn: Lars and the Real Internet of Things - Part 2

Mozilla planet - mo, 12/02/2018 - 22:27

In part 1 of this missive, I talked about my own checkered history of trying to control devices in my home.   Today I'm going to talk about setting up the Things Gateway software.

Disclaimers and Setting Expectations: The Things Gateway is an experimental proof of concept, not a polished commercial product.  It is aimed at the makers of the technology world, not someone expecting an effortless and flawless plug-and-play experience.  You will encounter glitches and awkward interfaces.  You may even have to interact with the Linux command line.

The Mozilla IoT Gateway is not yet either a functional equivalent or replacement for the commercial products. There are features missing that you will find in commercial products. It is the hope of Mozilla that this project will evolve into a full featured product, but that will take time and effort.

This is where we invite everyone in.  The Things Gateway is open source.  We encourage folks to participate, help add the missing features, help add support for more and more IoT capable things.
Goal: I want to get the Things Gateway by Mozilla up and running on a headless Raspberry Pi.  It will communicate with a smart light bulb and a smart plugin switch using a Zigbee adapter.  The IoT system will be configured for operation exclusively on the local network with no incoming or outgoing communication with the Internet.


Okay, we've had the history, the disclaimers and the goal, let's start controlling things.  If there are terms that I use and you don't know what they mean, look to the Mozilla Iot Glossary of Terms.

To work with the Things Gateway software, you're going to need some hardware.  I'm going to demonstrate using the ZigBee protocol and devices. To follow exactly what I'm going to do, you'll need to acquire the hardware or equivalents in the chart below.  In future articles, I'm going show how to add Z-Wave, Philips Hue, Ikea TRÅDFRI and TPLink hardware. Then I'll get into programming to add support to devices we've not even thought of yet.


ItemWhat's it for?Where I got itA laptop or desktop PCThis will be used to download the software and create the media that will boot the Raspberry PiI'm going to use my Linux workstation, any PC will doµSD Card ReaderNeeded only if there is no other way for the Desktop or Laptop to write to a µSD cardI used a Transcend TS-RDF5K that I bought on Amazon years ago Raspberry Pi Model 3 BThis is the single board computer that will run the Things Gateway. These are available from many vendors like Amazon and Adafruit5V µUSB Power SupplyThis supplies power to the Raspberry PiI had a spare one lying around, but you can probably get one from the vendor that sold the Raspberry Pi to you.µSD CardThis will essentially be the Raspberry Pi's hard driveI got mine in the checkout isle of the grocery store, it needs to be at least 4G DIGI XStickThis allows the Raspberry Pi to talk the ZigBee protocol - there are several models, make sure you get the XU-Z11 model.The only place that I could find this was Mouser ElectronicsCREE Connected ZigBee Compatible Light Bulb It's a thing to controlI got one from my local Home DepotSylvania SMART+ Plug ZigBee Compatible Appliance SwitchIt's a thing to controlI got this one from Amazon
Step 1: I downloaded the Things Gateway image file by pressing the Download button on the Build Your Own Web of Things page while using my Linux Workstation.  You should use a desktop or laptop. You can be successful using any OS, I just happen to be a Linux geek.

Step 2: I flashed the image onto my µSD card using my µSD Card Reader.  General instructions can be found on the installing images page. Since I'm using a Linux machine, I just used shell based tools like, lsblk and dd.  I had to identify my µSD card by its size.  I knew it would be the smallest device on my machine, so I identified it as the last on the lsblk list: sdh. Be very careful that you select the correct disk.  This is a very sharp knife, choosing the wrong disk could be a disaster.  Proceed at your own risk.
bozeman:~ ᚥ cd Downloads
bozeman:~/Downloads ᚥ unzip gateway-0.3.0.img.zip
bozeman:~/Downloads ᚥ lsblk | grep disk
sda 8:0 0 894.3G 0 disk
sdb 8:16 0 1.8T 0 disk
sdc 8:32 0 2.7T 0 disk
sdd 8:48 0 2.7T 0 disk
sde 8:64 0 2.7T 0 disk
sdf 8:80 0 2.7T 0 disk
sdh 8:112 1 14.4G 0 disk
bozeman:~/Downloads ᚥ sudo dd bs=4M if=gateway-0.3.0.img of=/dev/¿¿¿  # substitute your device name
[sudo] password for lars: **********
Because my Raspberry Pi is headless, having no keyboard or monitor, I need to have a way to communicate with it if something goes wrong. I'm going to enable the ssh server so I can connect to it from another computer.
bozeman:~/Downloads ᚥ mkdir rpi-boot
bozeman:~/Downloads ᚥ sudo mount /dev/¿¿¿1 rpi-boot  # substitute your device name
bozeman:~/Downloads ᚥ sudo touch rpi-boot/ssh
bozeman:~/Downloads ᚥ sudo umount rpi-boot
bozeman:~/Downloads ᚥ rmdir rpi-boot
bozeman:~/Downloads ᚥ
Step 3: I put the newly minted µSD card, the X-Stick and the network cable into my Raspberry Pi and applied power. It took about 45 seconds to boot to the point that the ssh server was working. While I waited, I set up my two test lamps.



Step 4: I'm going to depend on ssh to communicate with the Raspberry Pi, so I need to make sure ssh is secure. We can't let the "pi" account sit with the default password, so we must change it.
bozeman:~/Downloads ᚥ ssh pi@gateway.local
pi@gateway.local's password: raspberry
Linux gateway 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l
...
pi@gateway:~ $ passwd
Changing password for pi.
(current) UNIX password:raspberry
Enter new UNIX password: **********
Retype new UNIX password: **********
passwd: password updated successfully
pi@gateway:~ $ exit
logout
Connection to gateway.local closed.
bozeman:~/Downloads ᚥ



Step 5: By this time, the Thing Gateway web server was up and running and I connected to it with Firefox on my workstation.


I'd rather have my Gateway communicate over its Ethernet cable, so I don't want to setup WiFi.  I pressed Skip.


At this point in the setup, the Raspberry Pi is going to reboot.  For me, it took about two minutes before I was able to move on.
Step 6: After the delay, I retyped "gateway.local" into the URL bar to continue with the setup.  In this step, one would normally choose a subdomain so that their Things Gateway would be accessible from the Internet.  I do not intend to use that feature.


Again, I pressed Skip.



Step 6: Next, it registers a username and password.  I'll use this to login to the Things Gateway from my browser on my local network.  Notice that the Firefox URL Bar shows that this Web Site is insecure.  When you type your user name and password, you'll be warned again.

Because we're on our own network, this a tolerable situation for the moment.  We could add a self signed certificate and add a security exception to get rid of the warnings, but for now, I'm going to live with it.


Step 7: The Things Gateway is now up and running.  It shows us that it has not detected any devices yet.  However, before we move on, we can enable some more features in the Zigbee Adapter by updating it.  The simplest way to do that is to delete the Add-on that controls it and immediately reinstalling it.

Go to settings, by clicking the 3 horizontal bar drop-down menu icon in the upper left, selecting Settings, then Add-ons:


Remove the zigbee-adapter add-on:


Then Click the "+" and to add it back in.  This ensures we've got the latest code.  I think this is an awkward way to get an update, hopefully the project will improve that particular piece of UX.

Step 8: Leave settings by backing out using the Left Arrow buttons in the upper left until you're back to the Main Menu:


Select "Things"  Then press the "+" button.


Step 9: For me, it immediately found my two devices: the plug on/off switch and the CREE dimmable light bulb.  I gave them more understandable names, pressed "Save" on each and then "Done".


Step 10: Next I got to enjoy the ability to control lights from my computer for the the first time since the 1990s.  I explored the interface, and made a few rules.


In future editions in this series, I'm going to setup lighting for an old fashioned photo darkroom.  I want an easy way to switch between white and red safety lighting.  So I'll make a rule that will not allow both red and white lights to be on at the same time. This sounds like a perfect use of Philips Hue color changing bulb, eh?
Why do we need lighting for a photo darkroom?  I'll reveal that in a future blog post, too.


Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 12 Feb 2018

Mozilla planet - mo, 12/02/2018 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Don Marti: FOSDEM videos

Mozilla planet - sn, 10/02/2018 - 09:00

Check it out. The videos from the Mozilla room at FOSDEM are up, and here's me, talking about bug futures.

All FOSDEM videos

And, yes, the video link Just Works. Bonus link to some background on that: The Fight For Patent-Unencumbered Media Codecs Is Nearly Won by Robert O'Callahan

Another bonus link: FOSDEM video project, including what those custom boxes do.

Categorieën: Mozilla-nl planet

Dzmitry Malyshau: Feasibility of low-level GPU access on the Web

Mozilla planet - sn, 10/02/2018 - 05:16

This is a follow up to Defining the Web platform post from a year ago. It doesn’t try to answer questions but instead attempts to figure out what are the right questions to ask.

Trade-offs

As the talks within WebGPU community group progress, it becomes apparent that the disagreements lie in more domains than simply technical. It’s about what the Web is today, and what we want it to become tomorrow. The further we go towards the rabbit hole of low-level features, the more we have to stretch the very definition of the Web:

  1. harder to guarantee security:
    • if the descriptors can be purely GPU driven (like Metal argument buffers), the browser can’t guarantee that they point to owned and initialized GPU memory.
    • if there are many exposed flags for device capabilities, it’s easy for a script to fingerprint users based on that profile.
  2. harder to achieve portability:
    • any use of incoherent memory
    • rich memory types spectrum (like Vulkan memory types/heaps) means that different platforms would have to take different code paths if implemented correctly, and that’s difficult to test
  3. makes the API increasingly more complex to use, which Web developers may not welcome:
    • declaring a Vulkan like render pass with multiple passes is a challenge
  4. finally, all this goes into performance characteristics:
    • potentially lower CPU cost, given the bulk of validation work moved from the driver onto the browser
    • more consistent framerate, given better control of scheduled GPU work
Consistency

It is clear that the native API have reached decent consistency in their respective programming models. Both Metal and Vulkan appear to be positioned at their local maximas, while I can’t confidently state the same about NXT that is unclear:

/*| /**\ ?*? / | .. / \ ..... ? ? ? Metal Vulkan NXT

One can’t just take a small step away from an existing API and remain consistent. Finding a whole new local maxima is hard because it means that the previous API designers (Khronos, Microsoft, Apple) either haven’t discovered it or simply discarded it for being inferior. And while we have Microsoft and Apple representatives in the group, we lack the opinion of Vulkan designers from Khronos.

Origins

My first prototype was based on Metal, after which I had a chance to talk a lot about the future of Web GPU access with fellow Mozillians. The feedback I got was very consistent:

  • use existing Vulkan API, making necessary adjustments to provide security and portability
  • provide maximum possible performance by making a platform, let higher level libraries build on it and expose simpler APIs to the users

A similar position was expressed by some of the Vulkan Portability members. And this is where we’ve been going so far with the development of portability layer and experiments with Vulkan-based WebIDL implementation in Servo. Check out the recent talk at Fosdem 2018 as well as our 2017 report for more details. Unfortunately, this direction faces strong opposition from the rest of W3C group.

Portability

Interestingly, there is an existing precedent of providing a less portable Web platform API (quote from an article by Lin Clark):

SharedArrayBuffers could result in race conditions. This makes working with SharedArrayBuffers hard. We don’t expect application developers to use SharedArrayBuffers directly. But library developers who have experience with multithreaded programming in other languages can use these new low-level APIs to create higher-level tools. Then application developers can use these tools without touching SharedArrayBuffers or Atomics directly.

So if the question is “Does Web API have to be portable?”, the answer is a definite “no”. It’s a nice property, but not a requirement, and can be justified by other factors, such as performance. Speaking of which… the case for performance gains in SharedArrayBuffers appears to be strong, which convinced the browser vendors to agree on exposing this low-level API. Now, can we apply the same reasoning to get Vulkan level of explicitness and portability to the Web? Can we rely on user libraries to make it more accessible and portable? Having some performance metrics would be great, but obtaining them appears to be extremely difficult.

Note: currently SharedArrayBuffers are disabled on all browsers due to the high-resolution timers in them discovered to be exploitable. One could argue that this is related to them being low-level, and thus we shouldn’t take them as a good example for a Web API. This is countered by the fact that the disabling is temporary, and the usefulness of SABs is completely clear (see ECMA security issue, also note this comment).

Performance

What would be a good benchmark that shows the cost of memory barriers and types being implicit in the API?

  1. we need to have the same GPU-intensive workloads running on Vulkan and Metal, preferably utilizing multiple command queues and advanced features like multiple passes or secondary command buffers
  2. … on the same hardware, which means Windows installed on a MacBook. Even then, we may see the differences in how OS schedules hardware access, how drivers are implemented, how applications settings are configured on different OSes, etc.
  3. the code paths split between Vulkan/Metal should be fairly high. If it’s done via an API abstraction layer like Vulkan Portability, then the results are obviously going to be skewed towards this API. Splitting at high level means taking most advantage of the native API features, but also means more work for the developer.

Until that benchmarking is done, we can’t reasonably argue in favor of performance when there are concrete sacrifices in portability, API complexity (and security, to an extent) that come with it… Defending Vulkan-like approach goes like this:

  • A: pipeline barriers are confusing, error-prone, and not evidently fast, let’s make them implicit. Look, our native API does that, and it’s successful.
  • M: but… tracking the actual layout and access flags on our side is hard (for the backends that require them), and it gets really difficult when multiple queues are involved that share resources
  • G: let’s only share resources with immutable access flags then, and transition ownership explicitly between queues otherwise
  • A: manually synchronizing submissions between queues is hard to get right anyway, prone to portability issues, etc. Let’s only have a single queue!

And so it goes… one aspect leading to another, proving that the existing APIs are consistent and local maxima, and that Metal is technically easier to fit the shoes of the Web.

Result

Ok, this post is turning into a rant, rather inevitably… Sorry!

The unfortunate part of the story is that the group will not agree on an existing API, no matter what it is, because it would be biased towards a specific platform. And while Mozilla and Apple are at least conceptually aligned to existing API concepts, Google has been actively trying to come up with a new one in NXT. As a result, not only the multi-platform applications would have to add support for yet another API when ported to the Web, that API is also going to be targeted from native via Emscripten and/or WebAssembly, and Google is all into providing the standalone (no-browser) way of using it, effectively adding to the list of native APIs… Without any IHV backing, and promoted by… browser vendors? That is the path the group appears to be moving unconsciously in, instead of building on top of existing knowledge and research.

The current struggle of developing the Web GPU API comes down to many factors. One of the, if not the most, important ones here is that the parties have different end results envisioned. Some would like the JavaScript use to be nice, idiomatic, and error-resistant. Some mostly care about WebAssembly being fast. Some can’t afford a badly written application looking different on different mobile phones. Some can’t expect developers to be smart enough to use a complicated API. Some leave WebGL as a backup choice for a simple and accessible but slower API.

And the fact we are discussing this within W3C doesn’t help either. We don’t have immediate access to Khronos IHV experts and ISV advisory panels. We desperately need feedback from actual target users on what they want. Who knows, maybe the real answer is that we are better off without yet another API at all?

Categorieën: Mozilla-nl planet

Pages