The longer a tool takes to process an input event the less events that gets generated by the window system so you would have a bigger distances between mouse move events. (which could lead to gaps in brush spacing in a paint tool etc)
I guess you really want to measure mps - mouse events per second. ;-) The fps counter should work because when interacting the tool generates a redraw after each mouse event but you would need to try it to be sure. -- Brent From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron Sent: 31 July 2012 20:59 To: softimage@listproc.autodesk.com Subject: Re: SDK : caching the tool context pick buffer @brent, can i use softimage's fps counter to do speed testing? does that counter represent the entire ogl rendering pipeline? no biggie if not, i just didn't want to have to make my own profiling/fps counter. s On Mon, Jul 30, 2012 at 3:09 PM, Steven Caron <car...@gmail.com<mailto:car...@gmail.com>> wrote: well the CGeometryAccessor is a dump of everything too, but its just float/long data arrays instead of full fledged classes. at least i could cache this data easily without loops... should be a fun exercise, which is available here for anyone who is interested... https://github.com/caron/SimpleBrush On Mon, Jul 30, 2012 at 2:58 PM, Brent McPherson <brent.mcpher...@autodesk.com<mailto:brent.mcpher...@autodesk.com>> wrote: I would say use the GeometryAccessor but I have probably used the SDK less than most of you guys. ;-). One thing that always bugged me about GetPolygons and related geometry calls is that they return an array of *all* the polygons in the object so it is a really inefficient way to access a single polygon when you know its index. l_polymesh.GetPolygons().GetItem(l_compIdx); GeometryAccessor seems designed to address this shortcoming.
<<attachment: winmail.dat>>
