Re: Performance oddity with X over ADSL
Martin Vermeer wrote: On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. Furthermore, here directly at the machine, there is no difference in typing speed with or without a displayed graphics. (Closing the background xterm with all the debugging output does make a difference though :-) So, it really is an ADSL traffic problem, not a CPU time problem. I suppose there is still a full pixmap going to the server at every keypress. At what point in the code does this transfer happen? Can it be suppressed? - Martin -- Angus
Re: Performance oddity with X over ADSL
Angus Leeming wrote: Martin Vermeer wrote: On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. I would guess the problem is the repaint operation itself. The Painter should not trigger the transfer of the pixmap at all when the user modifies the documents text content. Normally with an X event driven architecture you never draw to screen outside the XExposeEvent/XGraphicsExposeEvent events. You tell the X-Server the region which is updated by the appli- cation an the X-Server requests the repaint by the mentioned events. Regards, Stephan
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 09:07:42AM +0100, Angus Leeming wrote: Martin Vermeer wrote: This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. Hmmm... yes, obviously there is graphics stuff going down the line at every character typed. Which as I understand, should not happen with your patch. I fail to see what we're doing wrong. Obviously. Same here. Furthermore, here directly at the machine, there is no difference in typing speed with or without a displayed graphics. (Closing the background xterm with all the debugging output does make a difference though :-) So, it really is an ADSL traffic problem, not a CPU time problem. I suppose there is still a full pixmap going to the server at every keypress. At what point in the code does this transfer happen? Can it be suppressed? - Martin -- Angus - Martin pgpLyzIcnVRLT.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
Stephan Witt wrote: I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. I would guess the problem is the repaint operation itself. The Painter should not trigger the transfer of the pixmap at all when the user modifies the documents text content. Normally with an X event driven architecture you never draw to screen outside the XExposeEvent/XGraphicsExposeEvent events. You tell the X-Server the region which is updated by the appli- cation an the X-Server requests the repaint by the mentioned events. Granted. I believe that the Qt frontend adheres to this model. I tried to use bitBlt as Martin suggested. No improvement AFAICS. See how it feels to you. -- Angus? src/frontends/qt2/qlimage.diff Index: src/frontends/qt2/QLPainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v retrieving revision 1.35 diff -u -p -r1.35 QLPainter.C --- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35 +++ src/frontends/qt2/QLPainter.C 28 Apr 2005 08:38:56 - @@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int static_castlyx::graphics::QLImage const (i); fillRectangle(x, y, w, h, LColor::graphicsbg); - qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h); + bitBlt (qp_-device(), x, y, qlimage.qimage(), 0, 0, w, h); }
Re: Performance oddity with X over ADSL
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Martin, does this patch fix the problem for you? It shoudl Angus buffer the pixmap. I am not sure I understand the patch: QLImage::QLImage(QLImage const other) : Image(other), original_(other.original_), - transformed_(other.original_) + transformed_(other.original_), + transformed_pixmap_(other.original_) Why is everything initialized from original_? Can't you just have QLImage use only Pixmaps? What may happen is that you create a new QPixmap everytime a copy is made, so it has to be downloaded. Isn't it possible to use something like + transformed_(other.transformed_), + transformed_pixmap_(other.transformed_pixmap_) JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote:
Angus Martin, does this patch fix the problem for you? It shoudl
Angus buffer the pixmap.
I am not sure I understand the patch:
QLImage::QLImage(QLImage const other)
: Image(other), original_(other.original_),
- transformed_(other.original_)
+ transformed_(other.original_),
+ transformed_pixmap_(other.original_)
Why is everything initialized from original_?
No reason. Well spotted.
Can't you just have QLImage use only Pixmaps?
It makes the transformation stuff much more complicated. I think that the
trick is to transform the QImage and to finally buffer the pixmap in
setPixmap_impl.
What may happen is that you create a new QPixmap everytime a copy is
made, so it has to be downloaded. Isn't it possible to use something
like
+ transformed_(other.transformed_),
+ transformed_pixmap_(other.transformed_pixmap_)
It looks like this makes all the difference. Patch attached. With this I
get similar performance down an ADSL line with and without visible images.
--
AngusIndex: src/frontends/qt2/QLImage.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.C,v
retrieving revision 1.34
diff -u -p -r1.34 QLImage.C
--- src/frontends/qt2/QLImage.C 6 Nov 2004 16:14:21 - 1.34
+++ src/frontends/qt2/QLImage.C 28 Apr 2005 09:20:21 -
@@ -112,7 +112,8 @@ QLImage::QLImage()
QLImage::QLImage(QLImage const other)
: Image(other), original_(other.original_),
- transformed_(other.original_)
+ transformed_(other.transformed_),
+ transformed_pixmap_(other.transformed_pixmap_)
{}
@@ -204,6 +205,7 @@ bool QLImage::setPixmap_impl(Params cons
break;
}
+ transformed_pixmap_ = transformed_;
return true;
}
Index: src/frontends/qt2/QLImage.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.h,v
retrieving revision 1.10
diff -u -p -r1.10 QLImage.h
--- src/frontends/qt2/QLImage.h 2 May 2004 12:45:26 - 1.10
+++ src/frontends/qt2/QLImage.h 28 Apr 2005 09:20:21 -
@@ -30,7 +30,7 @@ public:
static FormatList loadableFormats();
~QLImage();
- QImage const qimage() const { return transformed_; }
+ QPixmap const qpixmap() const { return transformed_pixmap_; }
private:
/// Create a copy
@@ -70,6 +70,8 @@ private:
/// The transformed image for display.
QImage transformed_;
+ /// Buffer the pixmap itself
+ QPixmap transformed_pixmap_;
};
} // namespace graphics
Index: src/frontends/qt2/QLPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
retrieving revision 1.35
diff -u -p -r1.35 QLPainter.C
--- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35
+++ src/frontends/qt2/QLPainter.C 28 Apr 2005 09:20:21 -
@@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int
static_castlyx::graphics::QLImage const (i);
fillRectangle(x, y, w, h, LColor::graphicsbg);
- qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
+ bitBlt(qp_-device(), x, y, qlimage.qpixmap(), 0, 0, w, h);
}
Re: Performance oddity with X over ADSL
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus It looks like this makes all the difference. Patch attached. Angus With this I get similar performance down an ADSL line with and Angus without visible images. Excellent :) JMarc
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: Jean-Marc Lasgouttes wrote: ... What may happen is that you create a new QPixmap everytime a copy is made, so it has to be downloaded. Isn't it possible to use something like + transformed_(other.transformed_), + transformed_pixmap_(other.transformed_pixmap_) It looks like this makes all the difference. Patch attached. With this I get similar performance down an ADSL line with and without visible images. -- Angus Thanks! This appears to do the job. - Martin pgpmOZl6Jzxuq.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: ... What may happen is that you create a new QPixmap everytime a copy is made, so it has to be downloaded. Isn't it possible to use something like + transformed_(other.transformed_), + transformed_pixmap_(other.transformed_pixmap_) It looks like this makes all the difference. Patch attached. With this I get similar performance down an ADSL line with and without visible images. -- Angus Just a wild idea: LyX is still producing incoming ADSL traffic at 0.5 kB/s while doing nothing, just containing a new doc and blinking the cursor. Shouldn't the server be able to do that all on its own? The relevant code appears to be showCursor/removeCursor in qscreen.C. I like my network connection quiet so I can spot unusual activity: call me paranoid. When not doing anything, it's only ntp querying a time server every so many seconds. I like it that way, like Helsinki traffic, not Cairo :-) - Martin pgphdQAX1l8Kd.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
Martin Vermeer wrote: Just a wild idea: LyX is still producing incoming ADSL traffic at 0.5 kB/s while doing nothing, just containing a new doc and blinking the cursor. Shouldn't the server be able to do that all on its own? The relevant code appears to be showCursor/removeCursor in qscreen.C. I'm sure that we can fix this using the same caching ideas. Remind me after the w/e. -- Angus
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: It looks like this makes all the difference. Patch attached. With this I get similar performance down an ADSL line with and without visible images. This is great! I don't see the delays anymore, I even get smooth scrolling through the region with the graphich. :-) Lyx 1.4 is now fine for work via ADSL. Now, if I could say the same about xfig . . . Helge Hafting
Re: Performance oddity with X over ADSL
Martin Vermeer wrote: > On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: >> On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: >> > Martin Vermeer wrote: >> >> > > Is there an easy way to make the drawing more parsimonious? We used >> > > to have that and it was horribly complicated, and Andre cleaned it >> > > up, as I remember. Would it be worth pursuing in this case? >> > >> > Martin, does this patch fix the problem for you? It shoudl buffer the >> > pixmap. >> > >> > -- >> > Angus >> >> No Angus, it does not help. Character input remains syrupy precisely and >> only when there is a graphic within the display window. >> >> Are you sure you caught all the expensive drawing operations? Shouldn't >> you be using bitblt? I don't understand this stuff at all. This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. > Furthermore, here directly at the machine, there is no difference in > typing speed with or without a displayed graphics. (Closing the > background xterm with all the debugging output does make a difference > though :-) > > So, it really is an ADSL traffic problem, not a CPU time problem. I > suppose there is still a full pixmap going to the server at every > keypress. At what point in the code does this transfer happen? Can it be > suppressed? > > - Martin -- Angus
Re: Performance oddity with X over ADSL
Angus Leeming wrote: Martin Vermeer wrote: On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. I would guess the problem is the repaint operation itself. The "Painter" should not trigger the transfer of the pixmap at all when the user modifies the documents text content. Normally with an X event driven architecture you never draw to screen outside the XExposeEvent/XGraphicsExposeEvent events. You tell the X-Server the region which is updated by the appli- cation an the X-Server requests the repaint by the mentioned events. Regards, Stephan
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 09:07:42AM +0100, Angus Leeming wrote: > Martin Vermeer wrote: > This is double buffering, right? > http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html > > I don't see why that will help in this case. You're complaining that we're > going up and down the ADSL line to retrieve an image when we should be > using the cached pixmap on your local machine. Hmmm... yes, obviously there is graphics stuff going down the line at every character typed. Which as I understand, should not happen with your patch. > I fail to see what we're doing wrong. Obviously. Same here. > > Furthermore, here directly at the machine, there is no difference in > > typing speed with or without a displayed graphics. (Closing the > > background xterm with all the debugging output does make a difference > > though :-) > > > > So, it really is an ADSL traffic problem, not a CPU time problem. I > > suppose there is still a full pixmap going to the server at every > > keypress. At what point in the code does this transfer happen? Can it be > > suppressed? > > > > - Martin > > -- > Angus - Martin pgpLyzIcnVRLT.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
Stephan Witt wrote: >> I don't see why that will help in this case. You're complaining that >> we're going up and down the ADSL line to retrieve an image when we >> should be using the cached pixmap on your local machine. >> >> I fail to see what we're doing wrong. Obviously. >> > > I would guess the problem is the repaint operation itself. > The "Painter" should not trigger the transfer of the pixmap > at all when the user modifies the documents text content. > > Normally with an X event driven architecture you never draw to > screen outside the XExposeEvent/XGraphicsExposeEvent events. > You tell the X-Server the region which is updated by the appli- > cation an the X-Server requests the repaint by the mentioned > events. Granted. I believe that the Qt frontend adheres to this model. I tried to use bitBlt as Martin suggested. No improvement AFAICS. See how it feels to you. -- Angus? src/frontends/qt2/qlimage.diff Index: src/frontends/qt2/QLPainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v retrieving revision 1.35 diff -u -p -r1.35 QLPainter.C --- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35 +++ src/frontends/qt2/QLPainter.C 28 Apr 2005 08:38:56 - @@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int static_cast(i); fillRectangle(x, y, w, h, LColor::graphicsbg); - qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h); + bitBlt (qp_->device(), x, y, (), 0, 0, w, h); }
Re: Performance oddity with X over ADSL
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Martin, does this patch fix the problem for you? It shoudl Angus> buffer the pixmap. I am not sure I understand the patch: QLImage::QLImage(QLImage const & other) : Image(other), original_(other.original_), - transformed_(other.original_) + transformed_(other.original_), + transformed_pixmap_(other.original_) Why is everything initialized from original_? Can't you just have QLImage use only Pixmaps? What may happen is that you create a new QPixmap everytime a copy is made, so it has to be downloaded. Isn't it possible to use something like + transformed_(other.transformed_), + transformed_pixmap_(other.transformed_pixmap_) JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote:
> Angus> Martin, does this patch fix the problem for you? It shoudl
> Angus> buffer the pixmap.
>
> I am not sure I understand the patch:
>
> QLImage::QLImage(QLImage const & other)
> : Image(other), original_(other.original_),
> - transformed_(other.original_)
> + transformed_(other.original_),
> + transformed_pixmap_(other.original_)
>
> Why is everything initialized from original_?
No reason. Well spotted.
> Can't you just have QLImage use only Pixmaps?
It makes the transformation stuff much more complicated. I think that the
trick is to transform the QImage and to finally buffer the pixmap in
setPixmap_impl.
> What may happen is that you create a new QPixmap everytime a copy is
> made, so it has to be downloaded. Isn't it possible to use something
> like
> + transformed_(other.transformed_),
> + transformed_pixmap_(other.transformed_pixmap_)
It looks like this makes all the difference. Patch attached. With this I
get similar performance down an ADSL line with and without visible images.
--
AngusIndex: src/frontends/qt2/QLImage.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.C,v
retrieving revision 1.34
diff -u -p -r1.34 QLImage.C
--- src/frontends/qt2/QLImage.C 6 Nov 2004 16:14:21 - 1.34
+++ src/frontends/qt2/QLImage.C 28 Apr 2005 09:20:21 -
@@ -112,7 +112,8 @@ QLImage::QLImage()
QLImage::QLImage(QLImage const & other)
: Image(other), original_(other.original_),
- transformed_(other.original_)
+ transformed_(other.transformed_),
+ transformed_pixmap_(other.transformed_pixmap_)
{}
@@ -204,6 +205,7 @@ bool QLImage::setPixmap_impl(Params cons
break;
}
+ transformed_pixmap_ = transformed_;
return true;
}
Index: src/frontends/qt2/QLImage.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.h,v
retrieving revision 1.10
diff -u -p -r1.10 QLImage.h
--- src/frontends/qt2/QLImage.h 2 May 2004 12:45:26 - 1.10
+++ src/frontends/qt2/QLImage.h 28 Apr 2005 09:20:21 -
@@ -30,7 +30,7 @@ public:
static FormatList loadableFormats();
~QLImage();
- QImage const & qimage() const { return transformed_; }
+ QPixmap const & qpixmap() const { return transformed_pixmap_; }
private:
/// Create a copy
@@ -70,6 +70,8 @@ private:
/// The transformed image for display.
QImage transformed_;
+ /// Buffer the pixmap itself
+ QPixmap transformed_pixmap_;
};
} // namespace graphics
Index: src/frontends/qt2/QLPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
retrieving revision 1.35
diff -u -p -r1.35 QLPainter.C
--- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35
+++ src/frontends/qt2/QLPainter.C 28 Apr 2005 09:20:21 -
@@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int
static_cast(i);
fillRectangle(x, y, w, h, LColor::graphicsbg);
- qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
+ bitBlt(qp_->device(), x, y, (), 0, 0, w, h);
}
Re: Performance oddity with X over ADSL
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> It looks like this makes all the difference. Patch attached. Angus> With this I get similar performance down an ADSL line with and Angus> without visible images. Excellent :) JMarc
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: > Jean-Marc Lasgouttes wrote: ... > > What may happen is that you create a new QPixmap everytime a copy is > > made, so it has to be downloaded. Isn't it possible to use something > > like > > + transformed_(other.transformed_), > > + transformed_pixmap_(other.transformed_pixmap_) > > It looks like this makes all the difference. Patch attached. With this I > get similar performance down an ADSL line with and without visible images. > > -- > Angus Thanks! This appears to do the job. - Martin pgpmOZl6Jzxuq.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: ... > > What may happen is that you create a new QPixmap everytime a copy is > > made, so it has to be downloaded. Isn't it possible to use something > > like > > + transformed_(other.transformed_), > > + transformed_pixmap_(other.transformed_pixmap_) > > It looks like this makes all the difference. Patch attached. With this I > get similar performance down an ADSL line with and without visible images. > > -- > Angus Just a wild idea: LyX is still producing incoming ADSL traffic at 0.5 kB/s while doing nothing, just containing a new doc and blinking the cursor. Shouldn't the server be able to do that all on its own? The relevant code appears to be showCursor/removeCursor in qscreen.C. I like my network connection quiet so I can spot unusual activity: call me paranoid. When not doing anything, it's only ntp querying a time server every so many seconds. I like it that way, like Helsinki traffic, not Cairo :-) - Martin pgphdQAX1l8Kd.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
Martin Vermeer wrote: > Just a wild idea: LyX is still producing incoming ADSL traffic at > 0.5 kB/s while doing nothing, just containing a new doc and blinking the > cursor. Shouldn't the server be able to do that all on its own? > > The relevant code appears to be showCursor/removeCursor in qscreen.C. I'm sure that we can fix this using the same caching ideas. Remind me after the w/e. -- Angus
Re: Performance oddity with X over ADSL
On Thu, Apr 28, 2005 at 10:28:34AM +0100, Angus Leeming wrote: > > It looks like this makes all the difference. Patch attached. With this I > get similar performance down an ADSL line with and without visible images. > This is great! I don't see the delays anymore, I even get smooth scrolling through the region with the graphich. :-) Lyx 1.4 is now fine for work via ADSL. Now, if I could say the same about xfig . . . Helge Hafting
Re: Performance oddity with X over ADSL
Martin Vermeer wrote: I don't think it has anything to do with moving the graphic. What I notice on my 256k/256k ADSL modem is traffic going on all the time when a document is open. It starts with the splash screen; when that is loaded, it stops. Then when you open a document or start a new one, it starts again and never stops. There is some inefficient redrawing going on somewhere. Cursor blink code? I wonder... One thing we do with graphics images is *monitor* the state of the original file. Does disabling this in support/FileMonitor.C make life better? -- Angus
Re: Performance oddity with X over ADSL
On Wed, 2005-04-27 at 10:41, Angus Leeming wrote: Martin Vermeer wrote: I don't think it has anything to do with moving the graphic. What I notice on my 256k/256k ADSL modem is traffic going on all the time when a document is open. It starts with the splash screen; when that is loaded, it stops. Then when you open a document or start a new one, it starts again and never stops. There is some inefficient redrawing going on somewhere. Cursor blink code? I wonder... One thing we do with graphics images is *monitor* the state of the original file. Does disabling this in support/FileMonitor.C make life better? Haven't tried that, but I did find the following when using the testing code: Index: QLPainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v retrieving revision 1.35 diff -u -p -r1.35 QLPainter.C --- QLPainter.C 31 Jan 2005 15:26:39 - 1.35 +++ QLPainter.C 27 Apr 2005 09:29:17 - @@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int static_castlyx::graphics::QLImage const (i); fillRectangle(x, y, w, h, LColor::graphicsbg); + lyxerr Drawing an image endl; qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h); } When placing an external xfig object and enabling its graphic display, the lyxerr printout is triggered once. Then, when typing characters even into paragraphs well below the graphic, _every time_ the printout is triggered. That's a lot of drawing work for a single character :-) Whan scrolling the graphic to outside the visible window, also the printouts disappear. Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? - Martin signature.asc Description: This is a digitally signed message part
Re: Performance oddity with X over ADSL
Index: QLPainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v retrieving revision 1.35 diff -u -p -r1.35 QLPainter.C --- QLPainter.C 31 Jan 2005 15:26:39 - 1.35 +++ QLPainter.C 27 Apr 2005 09:29:17 - @@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int static_castlyx::graphics::QLImage const (i); fillRectangle(x, y, w, h, LColor::graphicsbg); + lyxerr Drawing an image endl; qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h); } When placing an external xfig object and enabling its graphic display, the lyxerr printout is triggered once. Then, when typing characters even into paragraphs well below the graphic, _every time_ the printout is triggered. That's a lot of drawing work for a single character :-) Whan scrolling the graphic to outside the visible window, also the printouts disappear. Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? I'm no expert, but aren't we meant to redraw only the 'current' paragraph in such situations? -- Angus
Re: Performance oddity with X over ADSL
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I'm no expert, but aren't we meant to redraw only the 'current' Angus paragraph in such situations? Currently we redraw all visible paragraphs (plus a few more) AFAIK. JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote: Angus I'm no expert, but aren't we meant to redraw only the 'current' Angus paragraph in such situations? Currently we redraw all visible paragraphs (plus a few more) AFAIK. My initial reaction is that is crap. braindead. wrong. IMO. Of course, I'm sure that there is a logical explanation? -- Angus
Re: Performance oddity with X over ADSL
Angus == Angus Leeming [EMAIL PROTECTED] writes: Currently we redraw all visible paragraphs (plus a few more) AFAIK. Angus My initial reaction is that is crap. braindead. wrong. IMO. Angus Of course, I'm sure that there is a logical explanation? I am sure Andre' is much more able than I am to explain what the current situation is, but the idea was that the 1.3.x code was really too fragile. So it was nuked, and replaced by the current code, which almost does unconditional drawing (note that the metrics are cached, though). Concerning the previews, since the pixmap is already on the server, there should be a way to redraw it without doing a retransfer. Would using a QPixmap instead of a QImage help? It seems that drawImage has to do QImage-QPixmap anyway... JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote: Concerning the previews, since the pixmap is already on the server, there should be a way to redraw it without doing a retransfer. Would using a QPixmap instead of a QImage help? It seems that drawImage has to do QImage-QPixmap anyway... Yes, that sounds reasonable. -- Angus
Re: Performance oddity with X over ADSL
Martin Vermeer wrote:
On Wed, 2005-04-27 at 10:41, Angus Leeming wrote:
Martin Vermeer wrote:
I don't think it has anything to do with moving the graphic. What I
notice on my 256k/256k ADSL modem is traffic going on all the time
when a document is open. It starts with the splash screen; when that
is loaded, it stops. Then when you open a document or start a new one,
it starts again and never stops.
There is some inefficient redrawing going on somewhere. Cursor blink
code?
I wonder...
One thing we do with graphics images is *monitor* the state of the
original file. Does disabling this in support/FileMonitor.C make life
better?
Haven't tried that, but I did find the following when using the testing
code:
Index: QLPainter.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
retrieving revision 1.35
diff -u -p -r1.35 QLPainter.C
--- QLPainter.C 31 Jan 2005 15:26:39 - 1.35
+++ QLPainter.C 27 Apr 2005 09:29:17 -
@@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int
static_castlyx::graphics::QLImage const (i);
fillRectangle(x, y, w, h, LColor::graphicsbg);
+ lyxerr Drawing an image endl;
qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
}
When placing an external xfig object and enabling its graphic display,
the lyxerr printout is triggered once. Then, when typing characters even
into paragraphs well below the graphic, _every time_ the printout is
triggered. That's a lot of drawing work for a single character :-)
Whan scrolling the graphic to outside the visible window, also the
printouts disappear.
Is there an easy way to make the drawing more parsimonious? We used to
have that and it was horribly complicated, and Andre cleaned it up, as I
remember. Would it be worth pursuing in this case?
Martin, does this patch fix the problem for you? It shoudl buffer the
pixmap.
--
AngusIndex: src/frontends/qt2/QLImage.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.C,v
retrieving revision 1.34
diff -u -p -r1.34 QLImage.C
--- src/frontends/qt2/QLImage.C 6 Nov 2004 16:14:21 - 1.34
+++ src/frontends/qt2/QLImage.C 27 Apr 2005 21:44:22 -
@@ -112,7 +112,8 @@ QLImage::QLImage()
QLImage::QLImage(QLImage const other)
: Image(other), original_(other.original_),
- transformed_(other.original_)
+ transformed_(other.original_),
+ transformed_pixmap_(other.original_)
{}
@@ -204,6 +205,7 @@ bool QLImage::setPixmap_impl(Params cons
break;
}
+ transformed_pixmap_ = transformed_;
return true;
}
Index: src/frontends/qt2/QLImage.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.h,v
retrieving revision 1.10
diff -u -p -r1.10 QLImage.h
--- src/frontends/qt2/QLImage.h 2 May 2004 12:45:26 - 1.10
+++ src/frontends/qt2/QLImage.h 27 Apr 2005 21:44:22 -
@@ -30,7 +30,7 @@ public:
static FormatList loadableFormats();
~QLImage();
- QImage const qimage() const { return transformed_; }
+ QPixmap const qpixmap() const { return transformed_pixmap_; }
private:
/// Create a copy
@@ -70,6 +70,8 @@ private:
/// The transformed image for display.
QImage transformed_;
+ /// Buffer the pixmap itself
+ QPixmap transformed_pixmap_;
};
} // namespace graphics
Index: src/frontends/qt2/QLPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
retrieving revision 1.35
diff -u -p -r1.35 QLPainter.C
--- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35
+++ src/frontends/qt2/QLPainter.C 27 Apr 2005 21:44:23 -
@@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int
static_castlyx::graphics::QLImage const (i);
fillRectangle(x, y, w, h, LColor::graphicsbg);
- qp_-drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
+ qp_-drawPixmap(x, y, qlimage.qpixmap(), 0, 0, w, h);
}
Re: Performance oddity with X over ADSL
On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. - Martin pgpW6xJyFTBIs.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. - Martin Furthermore, here directly at the machine, there is no difference in typing speed with or without a displayed graphics. (Closing the background xterm with all the debugging output does make a difference though :-) So, it really is an ADSL traffic problem, not a CPU time problem. I suppose there is still a full pixmap going to the server at every keypress. At what point in the code does this transfer happen? Can it be suppressed? - Martin signature.asc Description: This is a digitally signed message part
Re: Performance oddity with X over ADSL
Martin Vermeer wrote: > I don't think it has anything to do with moving the graphic. What I > notice on my 256k/256k ADSL modem is traffic going on all the time when a > document is open. It starts with the splash screen; when that is loaded, > it stops. Then when you open a document or start a new one, it starts > again and never stops. > > There is some inefficient redrawing going on somewhere. Cursor blink > code? I wonder... One thing we do with graphics images is *monitor* the state of the original file. Does disabling this in support/FileMonitor.C make life better? -- Angus
Re: Performance oddity with X over ADSL
On Wed, 2005-04-27 at 10:41, Angus Leeming wrote: > Martin Vermeer wrote: > > I don't think it has anything to do with moving the graphic. What I > > notice on my 256k/256k ADSL modem is traffic going on all the time when a > > document is open. It starts with the splash screen; when that is loaded, > > it stops. Then when you open a document or start a new one, it starts > > again and never stops. > > > > There is some inefficient redrawing going on somewhere. Cursor blink > > code? > > I wonder... > > One thing we do with graphics images is *monitor* the state of the original > file. Does disabling this in support/FileMonitor.C make life better? Haven't tried that, but I did find the following when using the testing code: Index: QLPainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v retrieving revision 1.35 diff -u -p -r1.35 QLPainter.C --- QLPainter.C 31 Jan 2005 15:26:39 - 1.35 +++ QLPainter.C 27 Apr 2005 09:29:17 - @@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int static_cast(i); fillRectangle(x, y, w, h, LColor::graphicsbg); + lyxerr << "Drawing an image" << endl; qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h); } When placing an external xfig object and enabling its graphic display, the lyxerr printout is triggered once. Then, when typing characters even into paragraphs well below the graphic, _every time_ the printout is triggered. That's a lot of drawing work for a single character :-) Whan scrolling the graphic to outside the visible window, also the printouts disappear. Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? - Martin signature.asc Description: This is a digitally signed message part
Re: Performance oddity with X over ADSL
> Index: QLPainter.C > === > RCS file: > /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v > retrieving revision 1.35 > diff -u -p -r1.35 QLPainter.C > --- QLPainter.C 31 Jan 2005 15:26:39 - 1.35 > +++ QLPainter.C 27 Apr 2005 09:29:17 - > @@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int > static_cast(i); > > fillRectangle(x, y, w, h, LColor::graphicsbg); > + lyxerr << "Drawing an image" << endl; > qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h); > } > > When placing an external xfig object and enabling its graphic display, > the lyxerr printout is triggered once. Then, when typing characters even > into paragraphs well below the graphic, _every time_ the printout is > triggered. That's a lot of drawing work for a single character :-) > > Whan scrolling the graphic to outside the visible window, also the > printouts disappear. > > Is there an easy way to make the drawing more parsimonious? We used to > have that and it was horribly complicated, and Andre cleaned it up, as I > remember. Would it be worth pursuing in this case? I'm no expert, but aren't we meant to redraw only the 'current' paragraph in such situations? -- Angus
Re: Performance oddity with X over ADSL
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I'm no expert, but aren't we meant to redraw only the 'current' Angus> paragraph in such situations? Currently we redraw all visible paragraphs (plus a few more) AFAIK. JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote: > Angus> I'm no expert, but aren't we meant to redraw only the 'current' > Angus> paragraph in such situations? > > Currently we redraw all visible paragraphs (plus a few more) AFAIK. My initial reaction is that is "crap. braindead. wrong". IMO. Of course, I'm sure that there is a logical explanation? -- Angus
Re: Performance oddity with X over ADSL
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> Currently we redraw all visible paragraphs (plus a few more) >> AFAIK. Angus> My initial reaction is that is "crap. braindead. wrong". IMO. Angus> Of course, I'm sure that there is a logical explanation? I am sure Andre' is much more able than I am to explain what the current situation is, but the idea was that the 1.3.x code was really too fragile. So it was nuked, and replaced by the current code, which almost does unconditional drawing (note that the metrics are cached, though). Concerning the previews, since the pixmap is already on the server, there should be a way to redraw it without doing a retransfer. Would using a QPixmap instead of a QImage help? It seems that drawImage has to do QImage->QPixmap anyway... JMarc
Re: Performance oddity with X over ADSL
Jean-Marc Lasgouttes wrote: > Concerning the previews, since the pixmap is already on the server, > there should be a way to redraw it without doing a retransfer. Would > using a QPixmap instead of a QImage help? It seems that drawImage has > to do QImage->QPixmap anyway... Yes, that sounds reasonable. -- Angus
Re: Performance oddity with X over ADSL
Martin Vermeer wrote:
> On Wed, 2005-04-27 at 10:41, Angus Leeming wrote:
>> Martin Vermeer wrote:
>> > I don't think it has anything to do with moving the graphic. What I
>> > notice on my 256k/256k ADSL modem is traffic going on all the time
>> > when a document is open. It starts with the splash screen; when that
>> > is loaded, it stops. Then when you open a document or start a new one,
>> > it starts again and never stops.
>> >
>> > There is some inefficient redrawing going on somewhere. Cursor blink
>> > code?
>>
>> I wonder...
>>
>> One thing we do with graphics images is *monitor* the state of the
>> original file. Does disabling this in support/FileMonitor.C make life
>> better?
>
> Haven't tried that, but I did find the following when using the testing
> code:
>
> Index: QLPainter.C
> ===
> RCS file:
> /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
> retrieving revision 1.35
> diff -u -p -r1.35 QLPainter.C
> --- QLPainter.C 31 Jan 2005 15:26:39 - 1.35
> +++ QLPainter.C 27 Apr 2005 09:29:17 -
> @@ -171,6 +171,7 @@ void QLPainter::image(int x, int y, int
> static_cast(i);
>
> fillRectangle(x, y, w, h, LColor::graphicsbg);
> + lyxerr << "Drawing an image" << endl;
> qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
> }
>
> When placing an external xfig object and enabling its graphic display,
> the lyxerr printout is triggered once. Then, when typing characters even
> into paragraphs well below the graphic, _every time_ the printout is
> triggered. That's a lot of drawing work for a single character :-)
>
> Whan scrolling the graphic to outside the visible window, also the
> printouts disappear.
>
> Is there an easy way to make the drawing more parsimonious? We used to
> have that and it was horribly complicated, and Andre cleaned it up, as I
> remember. Would it be worth pursuing in this case?
Martin, does this patch fix the problem for you? It shoudl buffer the
pixmap.
--
AngusIndex: src/frontends/qt2/QLImage.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.C,v
retrieving revision 1.34
diff -u -p -r1.34 QLImage.C
--- src/frontends/qt2/QLImage.C 6 Nov 2004 16:14:21 - 1.34
+++ src/frontends/qt2/QLImage.C 27 Apr 2005 21:44:22 -
@@ -112,7 +112,8 @@ QLImage::QLImage()
QLImage::QLImage(QLImage const & other)
: Image(other), original_(other.original_),
- transformed_(other.original_)
+ transformed_(other.original_),
+ transformed_pixmap_(other.original_)
{}
@@ -204,6 +205,7 @@ bool QLImage::setPixmap_impl(Params cons
break;
}
+ transformed_pixmap_ = transformed_;
return true;
}
Index: src/frontends/qt2/QLImage.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLImage.h,v
retrieving revision 1.10
diff -u -p -r1.10 QLImage.h
--- src/frontends/qt2/QLImage.h 2 May 2004 12:45:26 - 1.10
+++ src/frontends/qt2/QLImage.h 27 Apr 2005 21:44:22 -
@@ -30,7 +30,7 @@ public:
static FormatList loadableFormats();
~QLImage();
- QImage const & qimage() const { return transformed_; }
+ QPixmap const & qpixmap() const { return transformed_pixmap_; }
private:
/// Create a copy
@@ -70,6 +70,8 @@ private:
/// The transformed image for display.
QImage transformed_;
+ /// Buffer the pixmap itself
+ QPixmap transformed_pixmap_;
};
} // namespace graphics
Index: src/frontends/qt2/QLPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLPainter.C,v
retrieving revision 1.35
diff -u -p -r1.35 QLPainter.C
--- src/frontends/qt2/QLPainter.C 31 Jan 2005 15:26:39 - 1.35
+++ src/frontends/qt2/QLPainter.C 27 Apr 2005 21:44:23 -
@@ -171,7 +171,7 @@ void QLPainter::image(int x, int y, int
static_cast(i);
fillRectangle(x, y, w, h, LColor::graphicsbg);
- qp_->drawImage(x, y, qlimage.qimage(), 0, 0, w, h);
+ qp_->drawPixmap(x, y, qlimage.qpixmap(), 0, 0, w, h);
}
Re: Performance oddity with X over ADSL
On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: > Martin Vermeer wrote: > > Is there an easy way to make the drawing more parsimonious? We used to > > have that and it was horribly complicated, and Andre cleaned it up, as I > > remember. Would it be worth pursuing in this case? > > Martin, does this patch fix the problem for you? It shoudl buffer the > pixmap. > > -- > Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. - Martin pgpW6xJyFTBIs.pgp Description: PGP signature
Re: Performance oddity with X over ADSL
On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: > On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: > > Martin Vermeer wrote: > > > > Is there an easy way to make the drawing more parsimonious? We used to > > > have that and it was horribly complicated, and Andre cleaned it up, as I > > > remember. Would it be worth pursuing in this case? > > > > Martin, does this patch fix the problem for you? It shoudl buffer the > > pixmap. > > > > -- > > Angus > > No Angus, it does not help. Character input remains syrupy precisely and > only when there is a graphic within the display window. > > Are you sure you caught all the expensive drawing operations? Shouldn't > you be using bitblt? I don't understand this stuff at all. > > - Martin Furthermore, here directly at the machine, there is no difference in typing speed with or without a displayed graphics. (Closing the background xterm with all the debugging output does make a difference though :-) So, it really is an ADSL traffic problem, not a CPU time problem. I suppose there is still a full pixmap going to the server at every keypress. At what point in the code does this transfer happen? Can it be suppressed? - Martin signature.asc Description: This is a digitally signed message part
Performance oddity with X over ADSL
Lyx 1.4cvs qt usually have nice performance over a 2Mb/s adsl link. (X tunneled via ssh.) The display update much faster than I can type - except if I insert an xfig external inset and checks show in lyx. I then get a nice image of the fig file, and performance drop to a level where I can type much faster than the display updates. This is strange and probably unnecessary. I understand that transferring an image over the adsl link will be slow, so I accept that any action that move the xfig-image on screen could be somewhat boring. But I was typing into another paragraph lower in the window, so the graphich didn't move at all. All that changes was a single line of text, there ought to be little X traffic and nice performance in this case. But it was awful - is graphichs repainted on every keystroke? Helge Hafting
Re: Performance oddity with X over ADSL
On Tue, Apr 26, 2005 at 09:17:48PM +0200, Helge Hafting wrote: Lyx 1.4cvs qt usually have nice performance over a 2Mb/s adsl link. (X tunneled via ssh.) The display update much faster than I can type - except if I insert an xfig external inset and checks show in lyx. I then get a nice image of the fig file, and performance drop to a level where I can type much faster than the display updates. This is strange and probably unnecessary. I understand that transferring an image over the adsl link will be slow, so I accept that any action that move the xfig-image on screen could be somewhat boring. But I was typing into another paragraph lower in the window, so the graphich didn't move at all. All that changes was a single line of text, there ought to be little X traffic and nice performance in this case. But it was awful - is graphichs repainted on every keystroke? Helge Hafting I don't think it has anything to do with moving the graphic. What I notice on my 256k/256k ADSL modem is traffic going on all the time when a document is open. It starts with the splash screen; when that is loaded, it stops. Then when you open a document or start a new one, it starts again and never stops. There is some inefficient redrawing going on somewhere. Cursor blink code? And the xforms version of LyX is still horrifically much slower than qt. - Martin pgpd2IU0hoflv.pgp Description: PGP signature
Performance oddity with X over ADSL
Lyx 1.4cvs qt usually have nice performance over a 2Mb/s adsl link. (X tunneled via ssh.) The display update much faster than I can type - except if I insert an xfig external inset and checks "show in lyx". I then get a nice image of the fig file, and performance drop to a level where I can type much faster than the display updates. This is strange and probably unnecessary. I understand that transferring an image over the adsl link will be slow, so I accept that any action that move the xfig-image on screen could be "somewhat boring". But I was typing into another paragraph lower in the window, so the graphich didn't move at all. All that changes was a single line of text, there ought to be little X traffic and nice performance in this case. But it was awful - is graphichs repainted on every keystroke? Helge Hafting
Re: Performance oddity with X over ADSL
On Tue, Apr 26, 2005 at 09:17:48PM +0200, Helge Hafting wrote: > Lyx 1.4cvs qt usually have nice performance over a 2Mb/s adsl > link. (X tunneled via ssh.) > > The display update much faster than I can type - except if I > insert an xfig external inset and checks "show in lyx". I then > get a nice image of the fig file, and performance drop to a level > where I can type much faster than the display updates. > > This is strange and probably unnecessary. I understand that transferring > an image over the adsl link will be slow, so I accept that any action that > move the xfig-image on screen could be "somewhat boring". > > But I was typing into another paragraph lower in the window, so the > graphich didn't move at all. All that changes was a single line of text, > there ought to be little X traffic and nice performance in this case. > But it was awful - is graphichs repainted on every keystroke? > > Helge Hafting I don't think it has anything to do with moving the graphic. What I notice on my 256k/256k ADSL modem is traffic going on all the time when a document is open. It starts with the splash screen; when that is loaded, it stops. Then when you open a document or start a new one, it starts again and never stops. There is some inefficient redrawing going on somewhere. Cursor blink code? And the xforms version of LyX is still horrifically much slower than qt. - Martin pgpd2IU0hoflv.pgp Description: PGP signature
