What is the fastest way to update overlaid graphics in a video?

Suppose you are given a 4D image array (I), where size(I,4) equals the number of frames in the image sequence. You also have a cell array (C) of centroids and radii for detected circles in a given frame. So, for instance, C{i} is an M-by-3 array of M detected circles in the ith frame.

What is the best way to render the detected circles while viewing the video, frame by frame?

I should mention that this will be embedded in an app that I am creating for tracking objects. My current approach is as follows:

1. I create a patch when the app is instantiated that has no visible faces or vertices.
2. When the frame changes, I compute the correct faces and vertices for the corresponding cell in C, and then update the patch using:

set(hpatch,'Faces',f,'Vertices',v)

It works ok, but it is slow if the number of detections is large (1000+ circles in an image). Would it be faster to draw each circle as its own graphics object instead of one patch object? My concern there is that the number of objects will likely change from frame to frame, so the number of graphics objects I will need is variable. Or would it be faster to overwrite the image with the detected objects (i.e. insertShape)?

Answer 1

[Mike Garrity]

Actually, it sounds like you're probably up against this case:

http://blogs.mathworks.com/graphics/2014/11/26/pretriangulation/

But there are a lot of great suggestions in the comment thread on the post that Walter linked to.

I'm basing my guess on the fact that you said that the performance is a function of the number of circles. A graph like the ones I used in this post might be helpful in isolating the cause.

[Matthew Eicholtz]

Thanks for the advice, Mike. I think pretriangulation may be a good place for me to start for speedup. Also, I only see 4 comments on the post Walter linked to and they do not seem applicable to my problem...am I missing something?

[Matthew Eicholtz]

I'm also thinking maybe I was not clear enough in my original question (my apologies for that). I am most interested in whether deleting and re-creating graphics objects is faster than editing properties of existing objects.

To give another example, I use quiver to show optical flow. Should I create a new quiver each time I update my optical flow or just manually edit the X,Y,U,V data of an existing quiver object?

[Mike Garrity]

Sorry, my bad. I thought that Walter had linked to this one:

<http://blogs.mathworks.com/graphics/2015/06/09/object-creation-performance/>

[Mike Garrity]

In general, modifying the properties of an existing object is going to be faster than creating a new object.

That's a bit of an oversimplification, and you should always profile both approaches if you're in a situation where you're going to be very performance sensitive.

The polygon thing is a bit of a special case. When you change the Vertices property of a patch object, it doesn't know whether it can reuse the old triangulation, so it does it from scratch. If you know that you haven't changed the topology of any of the faces, then you can score a win by using the triangulation.

Another thing to watch out for is the case where you're only changing a tiny part of your object. Imagine you had thousands of polygons, and one of them was moving around. If you stick them all into the same patch object, then MATLAB is going to retriangulate all of the faces and send all of the triangles to the graphics card. In this case, you can do much better by splitting it into two patch objects. Put all of the "static" faces in one, and all of the faces that are changing in the other. That way the big "static" patch will get parked in the memory system of the graphics card, and just the tiny "varying" patch will get pushed across the interconnect each frame.

[Matthew Eicholtz]

Thanks for all the help. Big fan of the Graphics blog...looks like I need to add it to my bookmarked pages.

Answer 2

[Walter Roberson]

http://blogs.mathworks.com/graphics/2015/01/20/performance-scaling/

[Matthew Eicholtz]

Thanks for the interesting link, but not quite what I am looking for.