New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webgl incorrect clipping, 0.12.11 onwards #7211

Closed
doiko opened this Issue Nov 14, 2017 · 16 comments

Comments

Projects
None yet
6 participants
@doiko

doiko commented Nov 14, 2017

When webgl is enabled and firefox is used after zooming or panning glyphs can go outside the axes.
Moving them back can also leave some "garbages" outside axes.

Can be reproduced in:
https://bokeh.pydata.org/en/latest/docs/user_guide/webgl.html
untitled

This issue do not appear at chrome, or edge

@mattpap

This comment has been minimized.

Contributor

mattpap commented Nov 14, 2017

Which version of Firefox and what platform?

@doiko

This comment has been minimized.

doiko commented Nov 14, 2017

Problem appears in Firefox 56.0 (64-bit), both standard and developer edition under Ubuntu 17.04 and 16.04.

@mattpap

This comment has been minimized.

Contributor

mattpap commented Nov 14, 2017

Are there any error in JS console? E.g.:

Error: WebGL warning: Failed to create WebGL context: WebGL creation failed: 
* Refused to create native OpenGL context because of blacklist entry: 
* Exhausted GL driver options.

I have exactly the same setup in my dev VM and on my host system, and in VM it works and fails on host. Anyway, what you observe here is that webgl wasn't allowed to be initialized (I suspect it's a configuration issue), so bokeh fell back to software rendering, but didn't properly set up clipping region (as this is done by webgl renderer if requested).

@mattpap

This comment has been minimized.

Contributor

mattpap commented Nov 14, 2017

@doiko

This comment has been minimized.

doiko commented Nov 14, 2017

Hi,
I am opening https://bokeh.pydata.org/en/latest/docs/user_guide/webgl.html
and the error I see is

Source map error: request failed with status 404
Resource URL: https://cdn.pydata.org/bokeh/release/bokeh-0.12.10.min.js
Source Map URL: bokeh.min.js.map

Working in a VM.

@AzraelDD

This comment has been minimized.

AzraelDD commented Dec 14, 2017

On my Windows laptop, I have the same problem. The rectangle where glyphs are displayed does not match with the figure axis.
In my case the problem appears in all browsers (Firefox, Chrome, Egde). At the same time, all of them show huge performance improvements with enabled webgl. So I assume that webgl is sort of working (i.e. not blocklisted), just not properly. I already tried a second Windows laptop which shows the same behaviour.
Is there anything I can do to help identify the cause of the issue?

Edit: I realized this has already been adressed and commented on in another issue (#6867)

@alexomics

This comment has been minimized.

alexomics commented Jan 17, 2018

Similar issues on MacOS. In Firefox, with webgl enabled, I only see overflow on the top or bottom axes on some plots (see below) Though it seems like the 'view' is just shifted in one direction.
bokeh_plot 1
bokeh_plot 3

Both from https://bokeh.pydata.org/en/latest/docs/user_guide/webgl.html

In Chrome, with webgl disabled, I see overflow on all sides.

Firefox console warning: bokeh-gl-0.12.13.min.js:1:12536

Error: WebGL warning: Drawing without vertex attrib 0 array enabled forces the browser to do expensive emulation work when running on desktop OpenGL platforms, for example on Mac. It is preferable to always draw with vertex attrib 0 array enabled, by using bindAttribLocation to bind some always-used attribute to location 0.

Chrome console warning: bokeh-0.12.13.min.js:sourcemap:1

bokeh-0.12.13.min.js:sourcemap:1 [bokeh] WebGL is not supported, falling back to 2D canvas.
e.init_webgl @ bokeh-0.12.13.min.js:sourcemap:1

Mac OS X 10.13.1
Chrome/63.0.3239.132
Firefox 57.0.4

@birdsarah birdsarah changed the title from webgl and firefox to webgl incorrect clipping, 0.12.11 onwards Mar 17, 2018

@birdsarah

This comment has been minimized.

Member

birdsarah commented Mar 17, 2018

I've updated the title, and marked as bug.

Go to User Guide -> Speeding up with WebGL

For 0.12.10 and then 0.12.11 onwards and I see this bug on Chrome and Firefox.

Am marking this one as other reportees are being directed here.

@birdsarah

This comment has been minimized.

Member

birdsarah commented Mar 17, 2018

Screenshot of Firefox on Linux 0.12.11

screenshot from 2018-03-17 16-10-40

@birdsarah

This comment has been minimized.

Member

birdsarah commented Mar 17, 2018

Screenshot of Chrome on OSX for 0.12.15dev3

screen shot 2018-03-17 at 4 12 14 pm

@birdsarah

This comment has been minimized.

Member

birdsarah commented Mar 17, 2018

Figured it wasn't worth screenshotting all the possible combinations in between.

@bryevdv

This comment has been minimized.

Member

bryevdv commented Mar 17, 2018

WebGL is currently a mess. Not surprising since it is not really under automated test at the moment, and there is no one spending time maintaining it. It might be possible to get SauceLabs test running again to help with WebGL. They broke when we refactored the build to switch to TravisCI stages. I was not able to get them working again, despite trying. More preferable to me personally tho, would be getting locally runnable image diff tests based off Chrome Headless working, since CH supports webgl.

Longer term I'd like to consider not supporting two backends, maybe basing BokehJS on ReGL for non-text rendering, but that's currently pie in the sky planning

@mattpap mattpap added the tag: webgl label Mar 22, 2018

@mattpap mattpap added this to the 0.12.15 milestone Mar 22, 2018

@mattpap mattpap self-assigned this Mar 22, 2018

@AzraelDD

This comment has been minimized.

AzraelDD commented Mar 23, 2018

I was quite excited for this fix, so I have cloned and built Bokeh 0.12.15dev6+1.ga2949b2.
While my personal main project now becomes usable with webgl (thank you so much!!!), it is still not perfect, I'm afraid.
To me it seems like single figures work fine, as well as the first figure in a grid or a row. However, drawing outside of the plot area still happens with the other figures. Please consider the following example:

import numpy as np
import bokeh
from bokeh.plotting import figure
from bokeh.io import curdoc
from bokeh.layouts import row

#backend = 'canvas'
backend = 'webgl'

N = 10000
np.random.seed(0)  # Fix random

x = np.random.normal(0, np.pi, N)
y = np.sin(x) + np.random.normal(0, 0.2, N)

p1 = figure(title='Works fine', output_backend=backend)
p1.circle(x, y, fill_alpha=0.1)

p2 = figure(title='Compare for blurriness', output_backend=backend)
p2.circle(x, y, fill_alpha=0.1)

x = np.linspace(0, 10*np.pi, N)
y = np.cos(x) + np.sin(2*x+1.25) + np.random.normal(0, 0.001, (N, ))

p3 = figure(title='Drawing outside plot area happens', output_backend=backend)
p3.line(x, y, color="#22aa22", line_width=3)

curdoc().add_root(row(p1, p2, p3))
curdoc().title = backend+' '+bokeh.__version__

... But maybe there is more to this and it deserves a new issue:

  • I also noticed that with webgl, all but the first figure in a grid or row have LOD-decimation activated (they turn grey while panning). So maybe this is somehow related?
  • Moreover, there is the topic of blurriness: In 0.12.13 all webgl plots are a little bit blurred. (Its very subtle though, on my 1080p Monitor.) However, in 0.12.15dev only the first figure is blurred.
  • My conclusion would be that only the first figure has webgl activated properly, because the other figures use a lod_factor and are not blurred.
  • This is hard to measure, but I also feel like 0.12.15dev webgl is not as responsive as 0.12.13

I hope those explanations make somewhat sense!

@mattpap

This comment has been minimized.

Contributor

mattpap commented Mar 23, 2018

I also noticed that with webgl, all but the first figure in a grid or row have LOD-decimation activated

webgl disables LOD, so if you see LOD-like behavior, webgl is off. This may be a recent regression in webgl initialization code.

@bryevdv

This comment has been minimized.

Member

bryevdv commented Mar 23, 2018

In any case that's a separate problem, so please file a new GH issue with this information

@mattpap

This comment has been minimized.

Contributor

mattpap commented Mar 23, 2018

It's completely broken (#7681).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment