line plotting on images with canvas add is super slow

[jhennawi]

Hi All,

The line plotting interface on ginga is really nice, but very slow. In some instances it actually crashes ginga or makes zooming in and out of images with lines plots super slow. Is there anyway to make this faster. I'm analyzing an image which is (4000,700), with around 30 line plots that cover the entire image spectral dimension (they are traces of echelle spectra). A png plot is attached.

Many Thanks! Joe Hennawi

[pllim]

Is this the Cuts plugin?

[pllim]

To pin down where the bottleneck is, please provide your workflow. And if you are still using the RC interface, the relevant code snippets. Thanks.

[ejeschke]

Hi Joe,

Plotting many items is one of the areas where we need to improve the performance on Ginga, but 30 lines with 30 text items should not be causing too much slowdown. And it certainly shouldn't ever be crashing--that's a bug. Any chance we can see the code that is drawing this so we can test it out?

[ejeschke]

Importantly: what are the lines--Path objects or Line objects?

[jhennawi]

Hi All,

Thanks for the quick reply. We are using the path object. Here is the code we are executing:

pstep = 1
canvas = viewer.canvas(ch._chname)
y = (np.arange(trace.size)[::pstep]).tolist()
xy = [trace[::pstep].tolist(), y]
points = list(zip(xy[0], xy[1]))
canvas.add(str('path'), points, color=str(color))

Thanks! Joe

[pllim]

Hard to tell without profiling, but maybe the bottleneck is here?

class Path(PolygonMixin, CanvasObjectBase):
    # ...
    @classmethod
    def idraw(cls, canvas, cxt):
        points = list(cxt.points)
        points.append((cxt.x, cxt.y))
        return cls(points, **cxt.drawparams)

[ejeschke]

but maybe the bottleneck is here?

No, that function is only used for interactive drawing (human drawing out a path).

Joe, how many points each path (roughly)?

If you get a crash, is there a stack trace with it. If there is crash that is first thing I want to fix.

[jhennawi]

The images are 4096 x 4096, so the is the number of points per path. We implemented a sub-sampling thing, but it makes the plot look worse.

Joe

On Wed, Nov 7, 2018 at 3:42 PM ejeschke notifications@github.com wrote:

but maybe the bottleneck is here?

No, that function is only used for interactive drawing (human drawing out a path).

Joe, how many points each path (roughly)?

If you get a crash, is there a stack trace with it. If there is crash that is first thing I want to fix.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ejeschke/ginga/issues/703#issuecomment-436819021, or mute the thread https://github.com/notifications/unsubscribe-auth/AIXjoyaRVSUMkGWChzBfe2a69L07xjMPks5us2_3gaJpZM4YDneU .

--

Joseph F. Hennawi Associate Professor Department of Physics Broida Hall, UC Santa Barbara Santa Barbara, CA 93106-9530 Phone: 805-893-3503 Mobile: 805-450-8697 E-mail: joe@ joe@physics.ucsb.eduphysics.ucsb.edu http://web.physics.ucsb.edu/~joe/ enigma.physics.ucsb.edu

[ejeschke]

So, 4096 points per path?

[jhennawi]

Right.

On Wed, Nov 7, 2018 at 4:06 PM ejeschke notifications@github.com wrote:

So, 4096 points per path?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ejeschke/ginga/issues/703#issuecomment-436824036, or mute the thread https://github.com/notifications/unsubscribe-auth/AIXjo0SHXPla4l1wMMyDfHUVu-oHn8nKks5us3V-gaJpZM4YDneU .

--

Joseph F. Hennawi Associate Professor Department of Physics Broida Hall, UC Santa Barbara Santa Barbara, CA 93106-9530 Phone: 805-893-3503 Mobile: 805-450-8697 E-mail: joe@ joe@physics.ucsb.eduphysics.ucsb.edu http://web.physics.ucsb.edu/~joe/ enigma.physics.ucsb.edu