Yes, perpetual workarounds are an issue, but we can't handle this sort of debugging at scale. Further, this would have been even faster (particularly for less-common hardware) if the reporter could tell us exactly which hardware an issue is present on. Historically, it has been difficult to reproduce many reported bugs, and playing telephone between gecko-dev/website-dev/user-with-issue is excruciating, and means that some bugs will literally go unfixed anyway.
We also *cannot* ship most workarounds with our driver blacklist info, since they usually require new code. Site-local workarounds are a strong desire for A-tier sites because we simply *cannot* respond fast enough, particularly on the Release branch. (or even late Beta) Ideally, we'll eventually have enough of a handle on the long tail of driver bugs that we can look at sunsetting this. We could include an entry in the blacklist download to force problematic hardware to expose this info (once we identify them as such!), while leaving believed-good hardware masked off. We could start putting this together already, though I don't know if we're confident enough in having any driver on the whitelist yet. On Tue, Jun 16, 2015 at 7:25 AM, Jeff Muizelaar <[email protected]> wrote: > A concrete example of this kind of thing occurred a little while ago > with Google Maps. They reported that users on G41 class hardware were > getting distortion when zoomed out in earth mode. This was because of > our switch to D3D11 ANGLE. When we got this report we were able to > reproduce the problem and block D3D11 ANGLE on that hardware. Google > Maps blacklists this hardware when it can detect it using > WEBGL_debug_renderer_info and if we had been exposing > WEBGL_debug_renderer_info we would not have found this problem as > quickly as we did. > > We would've been able to find this problem even faster if we had a > better way for users to get this information to websites. The current > process with Google Maps seems to require users to complain on their > forum, for Google to ask them for the output of dxdiag and for them to > manually see a pattern in the output. This is obviously a process with > very low success and it seems like we could do something to make it > better. > > -Jeff > > On Mon, Jun 15, 2015 at 9:18 PM, Jeff Muizelaar <[email protected]> > wrote: > > I'm concerned this will discourage websites from reporting WebGL > > issues because it will be easier just to block whatever device has the > > problem they're running in to. This creates an additional burden on > > the web developer and essentially creates the user agent problem all > > over again, but at much worse scale because of the wide range of > > possible devices. This may be manageable for very large developers > > like Google but I don't think it scales across web developers. We are > > typically in a better position to control and update any WebGL > > blacklist. > > > > I've suggested that creating an easy way to rely diagnostic > > information to a website in the event of a problem is a better > > solution for improving the overall quality of our WebGL implementation > > and sharing that benefit with all websites instead of just benefiting > > large properties like Google's. > > > > -Jeff > > > > On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert <[email protected]> > wrote: > >> Summary: > >> The WEBGL_debug_renderer_info extension allows for querying which driver > >> (and commonly GPU) a WebGL context is running on. Specifically, it > allows > >> querying the RENDERER and VENDOR strings of the underlying OpenGL > driver. > >> > >> By default, RENDERER and VENDOR queries in WebGL yield safe but useless > >> values. (For example, Gecko returns "Mozilla"/"Mozilla" for > >> RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and > >> UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the > >> underlying graphics driver. These values are combined to form the "WebGL > >> Renderer" field in about:support. On my system, these are: > >> * UNMASKED_RENDERER_WEBGL: "ANGLE (NVIDIA GeForce GT 750M Direct3D11 > vs_5_0 > >> ps_5_0)" > >> * UNMASKED_VENDOR_WEBGL: "Google Inc." [1] > >> > >> Bug: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1171228 > >> > >> Link To Standard: > >> > https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/ > >> > >> Do other browser engines implement this: > >> Chrome and IE implement this; Safari does not. > >> > >> Platform Coverage: All platforms. > >> > >> Current Target Release: Firefox 41 > >> > >> Related Preferences: > >> * "webgl.disable-debug-renderer-info" (default: false): Disable this > >> extension for unprivileged content. > >> * "webgl.renderer-string-override" (default: ""): Overrides > >> UNMASKED_RENDERER_WEBGL query result when non-empty. > >> * "webgl.vendor-string-override" (default: ""): Overrides > >> UNMASKED_VENDOR_WEBGL query result when non-empty. > >> > >> Security and Privacy Concerns: > >> * Traditional user-agent sniffing concerns. (Known antipattern) > >> * This info includes what GPU is being used, which may contribute to > >> marketing profiles. > >> * This info adds easily-accessible bits of entropy that improve > >> fingerprinting, reducing privacy. (Panopticlick and others have > >> demonstrated that this is already very effective) > >> > >> Web Developer Use-Cases: > >> * Sites can more easily and immediately identify and address concerns > >> caused by specific hardware or drivers. Currently, apps must > >> unconditionally workaround an issue until we can ship a fix via browser > >> updates.This can mean performance degradation for unaffected machines > for, > >> sometimes for weeks. > >> * Sites can collate and cross-reference drivers and hardware when > tracking > >> issues both user-reported and auto-detected, which both helps sites > >> identify problematic hardware, and helps browsers fix these issues in > turn. > >> * This allows sites to offer better estimates of performance, and offer > >> reasonable defaults for quality settings. > >> > >> [1] On Windows, we use ANGLE as an intermediary driver on top of D3D, > hence > >> the VENDOR string being "Google, Inc." and not "NVIDIA" here. > >> _______________________________________________ > >> dev-platform mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
