Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:07
    lovelylightningbug opened #2364
  • Aug 05 17:37
    djhoese commented #2339
  • Aug 05 17:35
    djhoese synchronize #2339
  • Aug 05 17:35
    djhoese ready_for_review #2339
  • Aug 05 17:34
    djhoese synchronize #2339
  • Aug 05 16:54
    djhoese synchronize #2339
  • Aug 05 15:58
    djhoese synchronize #2339
  • Aug 03 16:59
    brisvag synchronize #2350
  • Aug 02 16:05
    brisvag synchronize #2350
  • Aug 02 08:36
    brisvag synchronize #2350
  • Aug 01 15:18
    brisvag commented #2350
  • Aug 01 14:58
    brisvag synchronize #2350
  • Aug 01 14:26
    brisvag synchronize #2350
  • Aug 01 14:23
    brisvag synchronize #2350
  • Aug 01 09:53
    brisvag synchronize #2350
  • Jul 29 14:21
    djhoese commented #2363
  • Jul 29 08:44
    a7mad7aydar opened #2363
  • Jul 28 15:40

    brisvag on main

    fix marker size scaling Merge pull request #2359 from b… (compare)

  • Jul 28 15:40
    brisvag closed #2359
  • Jul 28 14:41
    djhoese labeled #2359
Lorenzo Gaifas
@brisvag
and of course if anything about the texture is changed by one visual, the other won't know about it and might find itself in an inconsistent state.
David Hoese
@djhoese

@brisvag Yes, this would require a new type of object in vispy. Like a DataSource object or something that has special properties/accessors for accessing the data in different ways and it would cache the GPU-level objects. Like maybe someone wants to use a 1D array provided to DataSource as a vertex buffer or maybe as a texture. The Visuals can request the specific format they need.

This type of object could even handle dask arrays and/or provide a tiling functionality where the Visuals using them attach to some events or assign a callback to the DataSource. Or maybe just tell the DataSource that they are attached. The DataSource gets an update from the user, the DataSource tells the Visual(s) that there was an update, the Visual updates anything it needs and redraws itself.

Complications: There are two conflicting but still similar ideas here. The idea of a data source (numpy array, dask array, etc) and the idea of a GPU-level object that is shared between Visuals. They should maybe be two different types of classes.

Lorenzo Gaifas
@brisvag
Yeah, this pretty much echoes what we've been floating over at napari for some time, to have a DataSourceobject :)
Cyrille Rossant
@rossant
btw we keep a close look at these discussions about data sources in our experimentations on a future VisPy 2.0 @almarklein @rougier
Lorenzo Gaifas
@brisvag
great :)
David Hoese
@djhoese
@rougier ( @brisvag ) Another point about consistent formatting, how much time do you spend formatting/aligning the code that you want a specific way? If you used a tool to do it then the answer would be no time at all. I will admit that for the "data in code" case that @brisvag brought up then that is more important to identify bugs in the future.
Nicolas P. Rougier
@rougier
Indenting code manually is part of my coding workflow. It gives me time to think about the code. This is also the reason I never use a debugger, to force me to understand where it breaks and to remember it.
David Hoese
@djhoese
I'm not sure how a debugger hinders you in doing that
Lorenzo Gaifas
@brisvag
I do spend some time formatting, just because I got used to some standards and they take just as much time as not using them (i.e: putting function arguments on new lines rather than ona single line when there's many of them), but I don't bother with stuff restructuring long nested list comprehensions or sorting imports, cause those are fixed automatically by tools and take more time to think about. Also, they don't really help me in writing, but they only help others in reading.
Lorenzo Gaifas
@brisvag
Btw, I'm gonna try to do the 0.11.0 release today; it seems that the the plot axis PRs will require more time (and more work), so It' not worth waiting for them!
Lorenzo Gaifas
@brisvag
0.11.0 is out! Hopefuly I did everything right :) not on conda yet!
David Hoese
@djhoese
@brisvag Thanks! Yesterday was a holiday in the US so I'm still catching up on emails today
I've merged the conda-forge PR
should be available for install in the next hour or so
Lorenzo Gaifas
@brisvag
sweet!
David Hoese
@djhoese

@brisvag and others, CI is failing now. Looks like an impossible to fix:

 ___________________________________ test_dpi ___________________________________
vispy/util/dpi/tests/test_dpi.py:11: in test_dpi
    dpi = get_dpi()
vispy/util/dpi/_linux.py:66: in get_dpi
    raise RuntimeError('could not determine DPI')
E   RuntimeError: could not determine DPI

We may need to have a "if we're running tests on CI then default to 100"

WARNING: could not determine DPI
WARNING: Could not load the Qt platform plugin "xcb" in "" even though it was found.
WARNING: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.
/home/runner/work/_temp/d6b424e8-09fa-46b3-95da-0073f0cbe448.sh: line 10:  5244 Aborted                 (core dumped) python -c "import vispy; print(vispy.sys_info())"
Lorenzo Gaifas
@brisvag
uh.
David Hoese
@djhoese
the Qt platform plugin warning is always there. The "xcb" is new I think
Lorenzo Gaifas
@brisvag
this is vaguely familiar... I remember similar errors when trying to use qt apps via ssh...
David Hoese
@djhoese

Looking at what I think is the repository that configures what ubuntu-latest maps to in CI, I think they just updated the images used: https://github.com/actions/virtual-environments/commits/main

Still the same major version of Ubuntu but newer

Yep, ubuntu image changed. Working job:

https://github.com/vispy/vispy/runs/7296668312?check_suite_focus=true

Virtual Environment
  Environment: ubuntu-20.04
  Version: 20220626.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20220626.1/images/linux/Ubuntu2004-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220626.1

Failing job:

https://github.com/vispy/vispy/runs/7303113757?check_suite_focus=true


Virtual Environment
  Environment: ubuntu-20.04
  Version: 20220710.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20220710.1/images/linux/Ubuntu2004-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220710.1
David Hoese
@djhoese
Same apt packages seem to be installed and same conda versions. I think this is a bug in the new image. Making an issue...
Lorenzo Gaifas
@brisvag
👍
I think we might be seeing a bunch of crasher in napari as well for the same reason
David Hoese
@djhoese
I've created actions/virtual-environments#5894 but probably need to do more debugging myself if I want them to give us any useful information
Ogi Moore
@j9ac9k
so I hate gitter with a passion, but I'm here since you all are awesome
David Hoese
@djhoese
haha thanks. FYI there is a vispy/vispy for regular users, but given we're talking about CI stuff this is a good place
anyway, I mentioned on twitter that I think a dependency of the ubuntu-latest image no longer depends on x11-utils so now we need to make sure we are adding it. Nothing else has changed except the base image.
Ogi Moore
@j9ac9k
yeah it's one of the reasons I have an exhaustive apt-get install... list, I try and put all packages needed there, even if they typically ship w/ base images
David Hoese
@djhoese
I've created a new PR with adding that x11-utils everywhere and adding an explicit check with xdpyinfo vispy/vispy#2356
we'll see how that goes otherwise I'll steal more dependencies from pyqtgraph
Ogi Moore
@j9ac9k
looks like your CI is all green now?
David Hoese
@djhoese
Yes. I had to install x11-utils and then things seemed to work fine. Thanks for pointing me to pyqtgraph's CI. It was a good sanity check
Ogi Moore
@j9ac9k
nice! yeah that crap is really annoying to troubleshoot
Gccxeon
@Gccxeon
Hi mates! Is there any working demo of how to use the geometry module to display a 3D arrow using vispy.geometry.generation.create_arrow in a scene?
David Hoese
@djhoese
@Gccxeon please use the vispy/vispy gitter for usage questions in the future. For this question, there is an ArrowVisual that you can use. It was originally designed for 2D arrows so the arrow heads are "flat" if i remember correctly but it should work in 3D
David Hoese
@djhoese
@brisvag and others, FYI I've been sick for the last 3 or 4 days. I'm just starting to catch up on the 120+ emails in my inbox
Lorenzo Gaifas
@brisvag
Ugh, rough! No rush :)
David Hoese
@djhoese
@brisvag do you want to meet today? Otherwise we can cancel
Lorenzo Gaifas
@brisvag
oh sorry, I thought it wasn't happening, judging by the emails! As you wish; for me, I think we can just move along async via PR comments, nothing urgent to discuss :)
David Hoese
@djhoese
@brisvag Sounds good.
I was just about to join the meeting
we'll do it next time
Lorenzo Gaifas
@brisvag
👍
David Hoese
@djhoese
@brisvag I have some big updates/releases going on at work today. I might not have a ton of time to give a full review of your PR but will try my best and merge it
Lorenzo Gaifas
@brisvag
No worries! Actually, @melonora (whom I coached a bit on this PR) wanted to contribute some tests to check that giving different data sizes to a texture does not break. So maybe we can wait for him to get to that and then merge :)
David Hoese
@djhoese
perfect
Lorenzo Gaifas
@brisvag
new test is merged, feel free to review whenever you have time :)
David Hoese
@djhoese
I think i forgot to post it hete but I'm pn vacation this week. @brisvag i don't remember where we left off with your dtype PR, but i thought it was in a good place, right? Feel free to merge if I'm remembering correctly