[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] GL_RENDERER string needed for performant apps

If we've never seen a RENDERER string before obviously we can't know much about it. We can then rely on the capabilities we are able to query to determine what the device is capable of. If it turns out not to be performant, we can adapt and potentially learn from that experience so that future users don't get any bad performance. As Brandon points out, we can learn from this a lot faster than new data can be pushed to browsers. It also turns out to be less of a problem because most (sadly not all) new GPUs are performant enough to matter less (nVidia's lowest end 800 series GPU will certainly across the board outperform the lowest end hardware we currently support).

Sanitizing the renderer string means that often the same GPU will give slightly different GL_RENDERER strings based on OS, driver, etc. We apply a sanitization process to attempt to extract a meaningful GPU identifier. We would be fine with only receiving the strings post sanitization, but defining a useful and common method for sanitization would be very difficult.


On Wed, Jan 15, 2014 at 2:30 PM, Brandon Jones <bajones@google.com> wrote:
I'll let a member of the Maps team answer how they handle new RENDERER strings, but the main point I was trying to make is that while the matrix is large no matter how you look at it, the chances that the browser vendors are going to be able to anticipate all the potential problem areas for your app are effectively zero. Not to mention that out of necessity the turnaround time for a browser reacting to new problems or hardware will be on the order of weeks (if we're lucky), while app developers can react far faster.

On Wed, Jan 15, 2014 at 2:22 PM, Mark Callow <callow.mark@artspark.co.jp> wrote:

On 2014/01/15 13:57, Brandon Jones wrote:
Maintaining a per-feature performance characteristics list like that would be incredibly difficult for several reasons:
  • There are a lot of features to test, and the list grows with extensions.
  • Features may work well in isolation, but interact badly with other features in unpredictable ways
  • Features may only perform badly in certain use-cases, but fine otherwise.
  • "Slow" is highly subjective.
  • There is a steady stream of new hardware coming out that the browsers would need to continuously test an maintain detailed performance characteristics for.
All of this makes it unreasonable for browsers to try and track this information, and makes the usefulness of it limited to developers. On the other hand, developers know the feature set they care about. By giving them a method to track performance vs. hardware we allow them to make intelligent decisions about when and how to react to known-bad configurations.

All of the problems you list are also problems for application developers. I think knowing the feature set of interest reduces the matrix by only a small amount.

What does Google Maps do when it encounters a unknown GL_RENDERER string?



注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.