On Mon, 23 Sep 2002, Amir Michail wrote: > I believe we can address the polling and cursor problems in LyX > under DRT by identifying a user action as follows: > > * an X input determines the start of an action (e.g., key press) > > * a burst of X outputs (e.g., screen draw requests) determine the end of the > action (e.g., show the corresponding letter on the screen) > > This way, frequent polling that doesn't update the screen will not extend an > action indefinitely. Of course, if certain actions do not result in the > screen being updated for long periods of times, then we will not identify > their ends. Is this an issue in LyX? Do all actions result in some screen > output relatively quickly?
I would think so for 95% of all cases. The only things that could be different is spell checking, exporting and converting stuff, previewing, and similar operations that can take some time. > BTW, we have written a paper on DRT that uses LyX as a running example. > See: > > http://www.cse.unsw.edu.au/~amichail/drt.pdf Very impressive. Wish this tool was available under Windows! ;-) > Feedback would be appreciated! We should be able to release a preliminary > version of this tool + full instructions for getting LyX to work later this > week. I wish you luck. If I should give you some feedback regarding the technology, then I think you could use time profiling to add a new dimension. When you are developing an interactive application, it is often difficult to optimize a certain isolated task, because when you profile the application, the profiling information will typically include a lot of noise from start-up, loading and rendering of the document, and then final exit of the application. This makes it harder to optimize, for instance, adding a huge table in a LyX document. Therefore, if you extended your data collection with time stamps, it might be possible to provide some relevant profiling information: When you click cursor up in a math inset, the most time is spent in X. Regards, Asger Alstrup Nielsen
