@blackbanana_gitlab What are you trying to accomplish? Everything we have is described here: https://vispy.org/
Admittedly it needs a lot of work. I would suggest as a beginner to use the SceneCanvas and look at the Gallery of examples for the "Scene". There are also resources linked on our website about OpenGL understanding the basics of that.
def _process_mouse_event(self, event, override_picked=False): prof = Profiler() # noqa next_picked = None # sync hack deliver_types = ['mouse_press', 'mouse_wheel'] if self._send_hover_events: deliver_types += ['mouse_move'] picked = self._mouse_handler if not override_picked else override_picked if picked is None: if event.type in deliver_types: picked = self.visual_at(event.pos) # NOTE: hack to sync other ViewBox, should check a sync dict or parameter of VisualNodes instead if type(picked) == ViewBox and not override_picked: next_picked = VisualNode._visual_ids # No visual to handle this event; bail out now if picked is None: return # Create an event to pass to the picked visual scene_event = SceneMouseEvent(event=event, visual=picked) # Deliver the event if override_picked: # we know ViewBox handles event directly so don't need to search parents and don't want to change _mouse_handler getattr(picked.events, event.type)(scene_event) elif picked == self._mouse_handler: # If we already have a mouse handler, then no other node may # receive the event if event.type == 'mouse_release': self._mouse_handler = None getattr(picked.events, event.type)(scene_event) else: # If we don't have a mouse handler, then pass the event through # the chain of parents until a node accepts the event. while picked is not None: getattr(picked.events, event.type)(scene_event) if scene_event.handled: if event.type == 'mouse_press': self._mouse_handler = picked break if event.type in deliver_types: # events that are not handled get passed to parent picked = picked.parent scene_event.visual = picked else: picked = None # If something in the scene handled the scene_event, then we mark # the original event accordingly. event.handled = scene_event.handled if next_picked: # propagate to synced node self._process_mouse_event(event, override_picked=next_picked)
For context my top level looks like this:
from vispy import plot as vp ... fig = vp.Fig(size=(800, 800), show=False) ohlc = fig[0, 0].ohlc_plot((x, o, h, l, c), line_pos, symbol='c', title='BTC/USD 1 Minute Candles', xlabel='Current (pA)', ylabel='Membrane Potential (mV)') lines_plot = fig[1, 0].plot((x, c)) grid = vp.visuals.GridLines(color=(0, 0, 0, 0.5)) grid.set_gl_state('translucent') fig[0, 0].view.add(grid)
This results in two Viewbox's being added to the SceneCanvas which contain the plots to be synced
@martianmartin Ok, so that hack works for you right now? I'm not sure I follow the details of this, but is the basic issue that the mouse event handler is finding the "picked" AxisVisual/Widget and call its mouse handler but it never "finds" the other axis visual? Oh or is it not the AxisVisual's mouse handler that is called but the ViewBox and the AxisVisual is responding to those changes? I'm trying to think of other ways this could be done.
Side node: Don't do
if type(picked) == ViewBoxand instead do
if isinstance(picked, ViewBox).
Hello I am having a strange issue with
Canvas.render(). I am creating a canvas with
scene.SceneCanvas and then a view with
canvas.central_widget.add_view() and placing image visuals withing that view. I then attach some vert filters to position the image visuals and some frag filters to correct their color and alter the alpha channel to blend the seams. My final view looks like the first image.
However once I try to render the canvas to the cpu it seems as if all of the frag filters are removed (notice the seams around the "H2"). I wonder if it is something to do with the order I apply my filters and if the rendering is happening before these filters are applied. If so is there a way to specify at which point in the pipeline the rendering happens? Thanks for the help!
@tjjdoman_gitlab I think we need more to go on. When you talk about calling
.render(), you are then saving that array to an image on disk? When you say "vert filters" and "frag filters", how exactly are you applying these? Is it possible for you to show us a minimal example?
It is hard to tell the difference between the images since they are different sizes...and I don't know what I'm looking at
@djhoese Here is a minimal example of the issue I am seeing:
from vispy.visuals.transforms import MatrixTransform import numpy as np import matplotlib.pyplot as plt from vispy import scene import vispy vispy.use('pyqt5') images = np.zeros(shape=(2, 2, 400, 400, 4), dtype=np.uint8) images[..., 3] = 255 images[1, 1, -200:, :, 3] = 100 images[1, 1, :, -200:, 3] = 100 images[1, 0, -200:, :, 3] = 100 images[0, 1, :, -200:, 3] = 100 images[0,0,..., 0] = 255 images[1,0,..., 1] = 255 images[0,1,..., 2] = 255 images[1,1,...,:3] = 255 s = scene.SceneCanvas(size=(600, 600), title='actual') view = s.central_widget.add_view() # if i comment out the below line my image changes to a gray square in the corner view.camera = 'panzoom' im = np.ndarray((2,2), dtype=object) for c, i in enumerate(np.ndindex(im.shape)): im[i] = scene.visuals.Image(images[i], parent=view.scene) imX = im[i] mat = np.eye(4) mat[3, 1] = -i * 200 mat[3, 0] = -i * 200 mat[3, 2] = 3 - c imX.transform = MatrixTransform(mat) imX.order = c imX.update() s.show() view.camera.set_range(x=(-200, 400), y=(-200, 400)) render = imX.parent.canvas.render() plt.figure() plt.imshow(render)
The image show on the canvas (left) shows 9 different color squares, while the rendered image (right) only shows 3 squares and 3 rectangles.
Thank you for any advice!
mat[3, 2] = -c * 100makes it work
@martianmartin There isn't much beyond the examples in the repository and the gallery: https://vispy.org/gallery/scene/index.html
That is a long and broad list of topics that you've asked about though. You've basically asked for how all of VisPy works. With the plotting API, things are even less documented as that interface was never really "finished" by the people who originally wrote it and we've been working more on improving the Visuals and SceneCanvas rather than plotting. If you have a specific question about how they interact I can try to answer as much as I can.
Over on napari/napari#3357 we noticed that canvas widgets have a default
_border_width of 1, which can result in unexpected/undesired borders. The only easy way I found to remove that border is to modify the vispy source to make the default
border_width parameter 0 instead.
Before I open any issues/PRs on vispy, I wanted to check a few of things.
_border_widthto be 0?
There are some code snippets on the napari issue, but I'm happy to try to create a minimal reproducer - napari's Qt widgets/layout are non-trivial, so it's very possible that the default 1-pixel transparent borders only cause an issue for us (e.g. because of the effective background color of some Qt widget). Though, when calling
grabFrameBuffer on the native Qt widget, we'll also getting that border, so I think that constrains where that color is coming from.
@andy-sweet Thanks for reaching out.
canvas.central_widget.add_view()(or whatever it is) create a Grid widget as a central_widget implicitly and then
ViewBoxwidget. But I think at least for the view you should be able to import the ViewBox class, instantiate it, then add it to the grid widget with
central_widget.add_widget(view, ...). At least I think so. I might be mixing up multiple interfaces.
Am I OK with border width being set to 0? Sure, probably. It will probably cause a lot of tests to fail. @almarklein @rougier @larsoner any memory of the border width stuff? Looks like it came from a PR by @campagnola in vispy/vispy#1030
@djhoese : thanks for the quick reply! I think you effectively solved this issue by educating me on
We have already have a
VispyCanvas that extends
SceneCanvas so by overriding the
SceneCanvas.central_widget property there and by passing
border_width=0 through to
add_view, I think I'm able to get the desired behavior in napari, so I think that's probably going to be enough.
So unless I'm get some pushback from other people on napari, or you are / someone else is really curious about how many and what tests fails, I'm probably going to avoid opening that PR for now.
border_width0, since the other border widths can be more easily controlled (e.g. in
Markers(for example), you can do that with
Compound._subvisuals.size(3 is the index of the