@pwinston The way I've always understood it is that OpenGL is drawing each GL Program one at a time. Each Visual in vispy is a GL Program so having to draw a lot of visuals means the GPU has to draw visual 1, then visual 2, then visual 3, and so on. The more visuals you add the longer it takes for vispy (and the GPU) to get back to the first visual for redrawing.
The number 6 was just something I remember hearing one user complaining about. I don't remember what they were actually doing. It could be more than that and obviously it depends on the hardware running it.
I am honestly also surprised by this performance but haven't had time to really figure out if this can be expected. That is, is it vispy's python that is slowing things down (the GLIR conversion, etc) or is it actually the GPU taking time to draw things. Because of my lack of time, it is usually easiest to tell users looking for frames per second to combine their visuals into as few visuals as possible. Typically they are doing things like making a ton of SphereVisuals, then they could just make a single MeshVisual, or something like that. So the optimizations is more obvious.
Oh and the tile atlas can be more thought of as a tile cache. Some outer logic is filling it with data based on camera events (pan/zoom) and filling it with the necessary data. The TiledImageVisual would just be told "the tiles were updated, here's the data, here's the coordinates, go". And of course as a "cache", it could hold more tiles than are being displayed and the TiledImageVisual is only told to display some of the tiles.
While this may require logic every frame, how would you do it with separate ImageVisuals? You'd still have to do the logic of what tile is shown and which one isn't, right?
@pwinston Vispy was rapidly developed by a group of scientists (mostly) many years ago. Almost none of them have time for the project any more. What you describe for SceneCanvas optimization is likely something they had planned, but is not currently implemented. For the last couple years, I've just been keeping vispy alive with minimal actual features being added (by me at least).
We are always accepting of pull requests so if you spot something while you're doing your work, please let us know as either a github issue or even as a pull request.
I think in general vispy tried to be as flexible and generic as possible. This may make it difficult to do things like sorting Visuals by shader or opacity. There are some features borrowed from the glumpy library that would perform better for some of this stuff (called "collections") that haven't gotten the full Visual/SceneCanvas treatment yet. This would likely help some users.
Try out the multiple ImageVisuals and see how it goes. It will likely work just fine and possibly perform just fine.
@robintwhite What cookbook are you referring to?
As the vispy installation instructions say the jupyter widget is considered experimental and in general should not be used for "operational" uses. It is more of a proof of concept. It works but suffers from some major performance issues for anything interactive or anything that updates over time quickly.
Given that Cyrille hasn't made a commit on vispy in years, I would recommend starting with the current installation instructions for getting anything to show up in a jupyter lab/notebook session.
FREETYPEPY_BUNDLE_FT=1to tell pip to install freetype-py from source and include the binaries of freetype. Otherwise, python 2.7 and 32-bit Windows was dropped in the last release: https://github.com/vispy/vispy/pull/1886#issuecomment-656992425