Error in WebGL does not get communicated #2544

Activity

1. etpinard commented on Apr 11, 2018

   

   etpinard

   on Apr 11, 2018

   Contributor

   More actions

   Hmm. I'm not sure about this one. Is there a robust way to do that? Do you have an idea what other WebGL libs (e.g. three.js) do in cases like this? We don't communicate SVG errors either (one ex: #2482)
2. LeanderK commented on Apr 11, 2018

   

   LeanderK

   on Apr 11, 2018

   Author

   More actions

   looks like i never encountered a svg-error!
   If I (or somebody else) uses plotly.js to implement for example a dashboard that visualizes important information and due to a webgl-error the graph is just empty, it might lead to the person drawing the wrong conclusions. Especially when an empty graph is a possible result (for example if I want to plot only the outliers of a dataset).
   I think the result of plotly.js should be either a trustable visualization or an error.

   I don't know the details and whether this is easy to implement, but this makes me not trust plotly.js, because I have at least one possibility where the information presented is just false and misleading.
3. alexcjohnson commented on Apr 11, 2018

   

   alexcjohnson

   on Apr 11, 2018

   Collaborator

   More actions

   @LeanderK I wholeheartedly agree with your sentiment here - any error that leaves the plot in a state that looks plausible but is in fact either missing or misrepresenting data must be a high priority for us to fix.

   The challenge with communicating (visually on the plot itself I gather, as you already have this indication in the console) is that some errors don't seem to be accessible from javascript, as far as I can tell. I've seen that with some of the DOM errors during SVG rendering, haven't really looked into it for WebGL but wouldn't be surprised if the same is true of some errors there, given how separated it is from javascript processing.

   With that in mind, we have four potential classes of bug:

   • Those that throw an error, accessible from javascript, late enough that the plot looks plausible but is in fact wrong
   • Those that throw an error early on, halting execution, so the plot is obviously incomplete
   • Those that throw an inaccessible error, like the DOM errors I mentioned above
   • Those that throw no errors, we just have a logic error or hit an unanticipated edge case

   Only the first class would be helped by visually reporting the error (the second we could report but the user already knows there's a problem), while the last class accounts for the majority of bugs we deal with. So I worry that if we were to visually report, it would not only miss most bugs but if users expected to see such a report they would be less likely to notice the bugs that don't show such a report.

   👍React with 👍1Reacted by Leander Kurscheidt
4. alexcjohnson commented on Apr 30, 2018

   

   alexcjohnson

   on Apr 30, 2018

   Collaborator

   More actions

   Closing - thanks for the fruitful discussion @LeanderK
5. alexcjohnson

   closed this as completedon Apr 30, 2018