Enrico Forestieri wrote:
On Sat, Nov 11, 2006 at 01:47:38AM +0100, Abdelrazak Younes wrote:
I was partly wrong. While disabling these methods definitely helps (with
the attached patch), the csrss.exe problem and the poor typing
performance at the end the doc is still there.
Abdel, csrss.exe takes a lot of cpu in 1.3.7, too, but this does not
automatically lead to slowness. Indeed, 1.3.7 has no problem at all
with The Problematic Document.
This is weird... Maybe something related to external processes that lyx
is launching... Maybe 1.3 was checking the forked process asynchronously
and 1.4 does it synchronously?
I really wonder why the slowness is only for the paragraph immediately
before or after a big equation...
I seem to remember something about a "brutefind" algorithm which was
restricted to the previous and following paragraph, but I have a vague
recolletion of it and maybe it has nothing to do with all of this.
Hum, apparently not, disabling these methods doesn't solve the problem.
Abdel.
Index: cursor.C
===================================================================
--- cursor.C (revision 15850)
+++ cursor.C (working copy)
@@ -88,6 +88,8 @@
DocIterator result;
+ return result;
+
DocIterator it = c;
it.top().pos() = 0;
DocIterator et = c;
@@ -122,6 +124,7 @@
bool bruteFind(LCursor & cursor,
int x, int y, int xlow, int xhigh, int ylow, int yhigh)
{
+ return true;
BOOST_ASSERT(!cursor.empty());
InsetBase & inset = cursor[0].inset();
BufferView & bv = cursor.bv();
@@ -177,6 +180,7 @@
/// moves position closest to (x, y) in given box
bool bruteFind3(LCursor & cur, int x, int y, bool up)
{
+ return true;
BufferView & bv = cur.bv();
int ylow = up ? 0 : y + 1;
int yhigh = up ? y - 1 : bv.workHeight();
