Animation gloo vs visuals

[Kai Muehlbauer]

Hi,

I'm currently working on displaying weather radar images using vispy
(bleeding edge).

For cartesian gridded data I use ImageVisual (which I derived from one
of the vispy examples). For polar data (theta, range) I found that
PolarTransform can be used with ImageVisual.

For testing I set up an data array (360x360) with a specific
azimuthal/radial pattern which is cyclic rolled. Checking the frame
rates I get less than 20 fps. See the example here:

https://github.com/kmuehlbauer/scripts/blob/master/vispy/animate_image.py

(For polar display, remove the #)

Then I tried to use gloo directly (also an adapted vispy-example) and
found that the frame rates improve to 60 fps.

https://github.com/kmuehlbauer/scripts/blob/master/vispy/animate_gloo.py

Unfortunately my efforts to recreate the polar transform in the shaders
weren't successful yet. (change commented section in FRAG_SHADER)

I found Nicolas example on shadertoy
(https://www.shadertoy.com/view/MsBSRm) but my knowledge of OpenGL and
glsl is still rather poor, to make use of it. At this point I'm lost on
how to adapt the shadertoy example to the gloo VERT and FRAG shaders.

I really appreciate any hints or pointers to get a more clearer view on
`gloo`. Could you also shed some light on the fsp issue and why there is
so much difference between visual and gloo?

Thanks in advance!

Cheers,
Kai

[Kai Muehlbauer]

Hi there,

after looking at several vispy examples and the shadertoy example again
I updated my example here:

https://github.com/kmuehlbauer/scripts/blob/master/vispy/animate_gloo.py

It's working like a charm. Thanks for providing such a great package.

Anyway, I'am still interested why the implementation using visuals is so
slow in contrast to using gloo directly. Is it an inherent issue or can
that be overcome in an following release?

Cheers,
Kai

--
Kai Muehlbauer
Meteorological Institute University of Bonn
Auf dem Huegel 20 | +49 228 739083
D-53121 Bonn | kai.mue...@uni-bonn.de

[Luke Campagnola]

In most cases, using visuals results in performance that is comparable to gloo. I don't immediately see anything wrong with your code, so some profiling will be needed to determine what causes the difference.

--
You received this message because you are subscribed to the Google Groups "vispy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vispy+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kai Mühlbauer]

Thanks Luke,

I did make some checks with vispy-cprofile switch and found that there
is a big amount of time consumed in the _gl2.py (glLinkProgram), which
isn't found in the gloo program.

I briefly looked over the code in ImageVisual and found that when using
set_data the _texture is set to None. This takes the draw-routine to
recreate the whole texture2d. In the gloo script I just use the set_data
of Texture2D. So this recreation may consume this much time.

To dig deeper I changed my on_draw routine to use set_data of Texture2d
directly and use the draw from underlying _program:

self.image._texture.set_data(np.float32(self.data))
self.image._program.draw('triangle_strip')

This actually runs with 60 fps, but I lost the 90deg shading and get a
black/white drawing only.

This is as far as my knowledge will take me. I would really like to use
the Visuals because of the easier setup and use. Do you see any way to
set new data to the ImageVisual without recreation of the whole
Texture2D. If this behaviour could be overcome I could also open an
issue on github.

Thanks again!

Cheers,
Kai

> Auf dem Huegel 20 | +49 228 739083 <tel:%2B49%20228%20739083>
> D-53121 Bonn | kai.mue...@uni-bonn.de
> <mailto:kai.mue...@uni-bonn.de>

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "vispy" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to vispy+un...@googlegroups.com

> <mailto:vispy%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "vispy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vispy+un...@googlegroups.com

> <mailto:vispy+un...@googlegroups.com>.

[Luke Campagnola]

Thanks! Yes, it does look like some changes were made to ImageVisual that cause it to modify the shader program. Could you open an issue for this? I'll try to take care of it in #928.

To unsubscribe from this group and stop receiving emails from it, send an email to vispy+un...@googlegroups.com.

[Kai Mühlbauer]

https://github.com/vispy/vispy/issues/974

Change heading and text appropriately if necessary.

Cheers,
Kai

> <mailto:kai.mue...@uni-bonn.de

> <tel:%2B49%20228%20739083> <tel:%2B49%20228%20739083>

> > D-53121 Bonn | kai.mue...@uni-bonn.de
> <mailto:kai.mue...@uni-bonn.de>

> > <mailto:kai.mue...@uni-bonn.de

> <mailto:kai.mue...@uni-bonn.de>>
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "vispy" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to vispy+un...@googlegroups.com
> <mailto:vispy%2Bunsu...@googlegroups.com>

> > <mailto:vispy%2Bunsu...@googlegroups.com
> <mailto:vispy%252Buns...@googlegroups.com>>.

> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "vispy" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to vispy+un...@googlegroups.com

> <mailto:vispy%2Bunsu...@googlegroups.com>
> > <mailto:vispy+un...@googlegroups.com