Thanks for all the info. It isn't a problem at all, I was just curious if it was a bug or not.
Yes, the gcode could be optimized, but it is a one-off with the gcode is coming out of a cam program so that isn't in the $0 budget :-) -Tom On May 16, 2011, at 12:44 PM, Chris Radek wrote: > On Mon, May 16, 2011 at 06:43:47PM +0300, Viesturs L??cis wrote: >> >> AFAIK that is the feature, which helps preventing overload of CPU and >> thus affecting realtime performance. I think it is better to have some >> lines not painted as You want rather than get ruined part. > > This is close to the right answer. Actually it prevents drawing an > excessive backplot affecting *nonrealtime* performance. The user > interface is nonrealtime. Sluggish response of the user interface can > cause delay in responding to a released jog key, for instance. > > Realtime performance (machine motion, step generation, etc) is not > affected by a sluggish user interface. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
