Re: Extension support: maybe not a binary yes/no

There's plenty of half-working drivers out there -- the functionality is
there, but not working exactly as expected. In this case, the extension
still provides helpful functionality, but driver-specific workarounds are
required. I've encountered plenty of driver-specific issues just through
WebGL alone, and this is after ANGLE patches quite a few things up. That
said, I don't see much benefit in a "suspicious" answer. Browsers can't be
expected to keep its list of "yes" vs. "suspicious" up to date, so
application code will probably also necessitate the same driver version
checks to enable the workarounds for both a "yes" and a "suspicious".

On Wed, Aug 14, 2019 at 8:26 AM Myles C. Maxfield <mmaxfield@apple.com>
wrote:

>
>
> On Aug 14, 2019, at 5:53 AM, Kevin Rogovin <kevinrogovin@invisionapp.com>
> wrote:
>
> 
> Hi,
>
>  On the discussion on Github on dual source blending,
> https://github.com/gpuweb/gpuweb/issues/391, it was brought up that some
> hardware declared support but it was buggy on some hardware. This led me to
> a more general thinking on extensions. There are other cases where a driver
> advertises an extension but it does not work correctly and the only way to
> know is to either run the test oneself or examine the GPU vendor and driver
> string (indeed SKIA has some of this). The thought is that a browser could
> provide information if it considers an extension, though advertised by the
> driver, it may not work always. So the extension query mechanism would have
> three different possible results: "yes", "no" or "yes, but the browser is
> suspicious of the driver's support".
>
>
> An extension that doesn’t work is hardly an extension at all.
>
> Under which circumstances would a browser advertise an extension as
> “suspicious” but not “no?”
>
> And, what would you expect an app to do when it encounters a “suspicious”
> extension?
>
> Given that there are so major browsers now (and even fewer web-engines),
> if a browser says the 3rd option, it can prod IHV's to fix the issue, since
> small ISV's have much smaller impact (and will need to implement
> work-arounds as well).
>
> Comments?
>
>  -Kevin
>
>

-- 
  Jasper