Path: news.mathworks.com!newsfeed-00.mathworks.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!y38g2000hsy.googlegroups.com!not-for-mail
From: "Chris P." <chris.peressotti@gmail.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Any way to speed up drawing of tiny patch object?
Date: Fri, 13 Jun 2008 08:03:09 -0700 (PDT)
Organization: http://groups.google.com
Lines: 58
Message-ID: <75e7f622-415a-4d21-aa47-d58154e3c1d0@y38g2000hsy.googlegroups.com>
References: <c99b0c35-4eca-4087-981d-ac5489bd7849@p25g2000hsf.googlegroups.com> 
NNTP-Posting-Host: 142.76.1.62
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1213369389 11769 127.0.0.1 (13 Jun 2008 15:03:09 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 13 Jun 2008 15:03:09 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: y38g2000hsy.googlegroups.com; posting-host=142.76.1.62; 
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) 
Xref: news.mathworks.com comp.soft-sys.matlab:473666



> There are several ways to specify patches. The
> documentation is not the greatest. One way is to specify
> the faces and vertices.

I'd seen that (and figured out how it would be done) but didn't
explore it since it seemed to imply that it's faster only for a patch
with many faces... however, I decided to do my own tic-tocing and drew
the patch twice for each click -- once by giving the vertices directly
to patch (I call this "(x,y)", below), and once by creating vertices/
faces matrices and sending those to patch ("(v,f)", below).  I did ten
measurements (just listing a few, below):

(x,y)	        (v,f)	        (v,f)/(x,y)
0.000802	0.000359	0.45
0.000809	0.000509	0.63
...             ...             ...
0.000965	0.00037	        0.38
0.000972	0.000458	0.47

The avg of the last column is .48, so (v,f) takes approximately half
the time.  This is academically interesting, but... these numbers show
me that it really ISN'T patch that's causing the problem!  According
to these numbers, it's taking less than 1 ms to draw the patch, and
the pathologist won't notice the difference between 1 ms and 0.5 ms.

I'm picking these points within a "while" loop, so I placed my tic-toc
around the ginput statement such that "toc" would be a measure of the
entire time taken between picking a point, processing the result,
drawing the patch, and being ready to pick the next point:
fprintf('%2.2f seconds from ginput-to-ginput\n', toc);
[ginput_x,ginput_y,ginput_button] = ginput(1);
tic

and these times resulted:
0.000818 seconds from ginput-to-ginput
0.000778 seconds from ginput-to-ginput
0.000783 seconds from ginput-to-ginput

Again, WTF?  These are < 1 ms!  So I then rearranged my tic-toc like
so, and made sure I was ready to click the next next as soon as I saw
the crosshairs for ginput appear:
[ginput_x,ginput_y,ginput_button] = ginput(1);
fprintf('%2.2f seconds from ginput-to-AFTER-ginput\n', toc);
tic

and these times resulted:
1.38 seconds from ginput-to-AFTER-ginput
1.36 seconds from ginput-to-AFTER-ginput
1.35 seconds from ginput-to-AFTER-ginput

SO, the problem is somewhere in ginput itself, yes?  Does anyone have
any ideas?  (I'm going to go through ginput with a fine-toothed comb
right now, but I thought I'd give this update in case anyone has a
quick answer.)

Thanks for your help so far,

- Chris