Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,

I'll send a patch tomorrow but you can already test if the patch I sent earlier 
has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This is 
completely untested because I cannot link qt2 frontend anymore. But it 
should work. If would be good to test the two patches independently and 
then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.

Thanks,
Abdel.




Abdel.


-Original Message-
From: Bennett Helm [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:39 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:


Reading this thread, I see that the problem was mainly on MacOSX.  
If somebody is willing to test on this platform, I can provide a  
patch that will remove this key buffering in the qt2 frontend.


That would be me: I'm happy to test.

Bennett




This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.




Index: QContentPane.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.37
diff -u -r1.37 QContentPane.C
--- QContentPane.C  26 Nov 2005 20:28:38 -  1.37
+++ QContentPane.C  25 Jan 2006 14:55:04 -
@@ -91,7 +91,7 @@
boost::bind(QContentPane::generateSyntheticMouseEvent,
this));

-   connect(step_timer_, SIGNAL(timeout()), SLOT(keyeventTimeout()));
+// connect(step_timer_, SIGNAL(timeout()), SLOT(keyeventTimeout()));

setFocusPolicy(QWidget::WheelFocus);
setFocus();
@@ -106,7 +106,7 @@
this, SLOT(scrollBarChanged(int)));

// Start the timer, one-shot.
-   step_timer_.start(50, true);
+// step_timer_.start(50, true);
 }


@@ -264,7 +264,10 @@

 void QContentPane::keyPressEvent(QKeyEvent * e)
 {
-   keyeventQueue_.push(boost::shared_ptrQKeyEvent(new QKeyEvent(*e)));
+// keyeventQueue_.push(boost::shared_ptrQKeyEvent(new QKeyEvent(*e)));
+boost::shared_ptrQLyXKeySym sym(new QLyXKeySym);
+sym-set(e);
+wa_-workAreaKeyPress(sym, q_key_state(e-state()));
 }
Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()-repaint(
+   owner_.getContent()-update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   nocursor_pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   -repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   -update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 25, 2006, at 10:04 AM, Abdelrazak Younes wrote:


YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,
I'll send a patch tomorrow but you can already test if the patch I  
sent earlier has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This  
is completely untested because I cannot link qt2 frontend anymore.  
But it should work. If would be good to test the two patches  
independently and then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.


I haven't done any precise measurements, but I don't notice any  
effect from applying both patches at the same time. (I don't have  
time to test separately now, and it seems from my experience thus far  
like it wouldn't give new information.)


In a large-ish document, in the middle of a paragraph, I kept a key  
pressed, and the amount of time it takes to fill 2 lines of text is  
about the same for the patched and unpatched versions. Keeping the  
down arrow pressed, I don't notice any subjective difference (though  
I didn't try to quantify this case). Keeping PageDown pressed, it  
takes about the same amount of time to page through the entire  
document. Both patched and unpatched versions were able to keep up  
with my typing without dropping characters, and I wasn't able to  
notice any obvious difference in processor usage as I did this.


So, it seems that the patch doesn't have effects noticeable to the  
user on Mac.


Bennett

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Bennett Helm a écrit :

On Jan 25, 2006, at 10:04 AM, Abdelrazak Younes wrote:


YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,
I'll send a patch tomorrow but you can already test if the patch I 
sent earlier has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This is 
completely untested because I cannot link qt2 frontend anymore. But it 
should work. If would be good to test the two patches independently 
and then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.


I haven't done any precise measurements, but I don't notice any effect 
from applying both patches at the same time. (I don't have time to test 
separately now, and it seems from my experience thus far like it 
wouldn't give new information.)


Actually, applying the RemoveKeventqueue patch alone should make a 
difference WRT unpatched lyx. If not, then the reason why this 
keyventqueue has been introduced is not valid anymore.


Thanks for testing this,
Abdel.



In a large-ish document, in the middle of a paragraph, I kept a key 
pressed, and the amount of time it takes to fill 2 lines of text is 
about the same for the patched and unpatched versions. Keeping the down 
arrow pressed, I don't notice any subjective difference (though I didn't 
try to quantify this case). Keeping PageDown pressed, it takes about the 
same amount of time to page through the entire document. Both patched 
and unpatched versions were able to keep up with my typing without 
dropping characters, and I wasn't able to notice any obvious difference 
in processor usage as I did this.


So, it seems that the patch doesn't have effects noticeable to the user 
on Mac.


Bennett

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,

I'll send a patch tomorrow but you can already test if the patch I sent earlier 
has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This is 
completely untested because I cannot link qt2 frontend anymore. But it 
should work. If would be good to test the two patches independently and 
then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.

Thanks,
Abdel.




Abdel.


-Original Message-
From: Bennett Helm [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:39 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:


Reading this thread, I see that the problem was mainly on MacOSX.  
If somebody is willing to test on this platform, I can provide a  
patch that will remove this key buffering in the qt2 frontend.


That would be me: I'm happy to test.

Bennett




This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.




Index: QContentPane.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.37
diff -u -r1.37 QContentPane.C
--- QContentPane.C  26 Nov 2005 20:28:38 -  1.37
+++ QContentPane.C  25 Jan 2006 14:55:04 -
@@ -91,7 +91,7 @@
boost::bind(::generateSyntheticMouseEvent,
this));

-   connect(_timer_, SIGNAL(timeout()), SLOT(keyeventTimeout()));
+// connect(_timer_, SIGNAL(timeout()), SLOT(keyeventTimeout()));

setFocusPolicy(QWidget::WheelFocus);
setFocus();
@@ -106,7 +106,7 @@
this, SLOT(scrollBarChanged(int)));

// Start the timer, one-shot.
-   step_timer_.start(50, true);
+// step_timer_.start(50, true);
 }


@@ -264,7 +264,10 @@

 void QContentPane::keyPressEvent(QKeyEvent * e)
 {
-   keyeventQueue_.push(boost::shared_ptr(new QKeyEvent(*e)));
+// keyeventQueue_.push(boost::shared_ptr(new QKeyEvent(*e)));
+boost::shared_ptr sym(new QLyXKeySym);
+sym->set(e);
+wa_->workAreaKeyPress(sym, q_key_state(e->state()));
 }
Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()->repaint(
+   owner_.getContent()->update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   _pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   ->repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   ->update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 25, 2006, at 10:04 AM, Abdelrazak Younes wrote:


YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,
I'll send a patch tomorrow but you can already test if the patch I  
sent earlier has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This  
is completely untested because I cannot link qt2 frontend anymore.  
But it should work. If would be good to test the two patches  
independently and then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.


I haven't done any precise measurements, but I don't notice any  
effect from applying both patches at the same time. (I don't have  
time to test separately now, and it seems from my experience thus far  
like it wouldn't give new information.)


In a large-ish document, in the middle of a paragraph, I kept a key  
pressed, and the amount of time it takes to fill 2 lines of text is  
about the same for the patched and unpatched versions. Keeping the  
down arrow pressed, I don't notice any subjective difference (though  
I didn't try to quantify this case). Keeping PageDown pressed, it  
takes about the same amount of time to page through the entire  
document. Both patched and unpatched versions were able to keep up  
with my typing without dropping characters, and I wasn't able to  
notice any obvious difference in processor usage as I did this.


So, it seems that the patch doesn't have effects noticeable to the  
user on Mac.


Bennett

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Bennett Helm a écrit :

On Jan 25, 2006, at 10:04 AM, Abdelrazak Younes wrote:


YOUNES Abdelrazak (M3SYSTEM) a écrit :

Hello Bennett,
I'll send a patch tomorrow but you can already test if the patch I 
sent earlier has any impact on performance on MacOSX.


Hi Bennet,
Please find attached the patch that remove the key buffering. This is 
completely untested because I cannot link qt2 frontend anymore. But it 
should work. If would be good to test the two patches independently 
and then both at the same time. The test cases are:

- Keep a character key pressed (ex: 'a')
- Keep the down arrow key pressed
- Keep the PageDown key pressed
- Type as fast as you can and see if there are any character dropped.


I haven't done any precise measurements, but I don't notice any effect 
from applying both patches at the same time. (I don't have time to test 
separately now, and it seems from my experience thus far like it 
wouldn't give new information.)


Actually, applying the RemoveKeventqueue patch alone should make a 
difference WRT unpatched lyx. If not, then the reason why this 
"keyventqueue" has been introduced is not valid anymore.


Thanks for testing this,
Abdel.



In a large-ish document, in the middle of a paragraph, I kept a key 
pressed, and the amount of time it takes to fill 2 lines of text is 
about the same for the patched and unpatched versions. Keeping the down 
arrow pressed, I don't notice any subjective difference (though I didn't 
try to quantify this case). Keeping PageDown pressed, it takes about the 
same amount of time to page through the entire document. Both patched 
and unpatched versions were able to keep up with my typing without 
dropping characters, and I wasn't able to notice any obvious difference 
in processor usage as I did this.


So, it seems that the patch doesn't have effects noticeable to the user 
on Mac.


Bennett

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

Andre There is indeed no reason (in theory) for us to use repaint().
Andre update() just does the right thing, possibly combining repeated
Andre request to a single one.

Andre In practivce, there might have been a reason at some point of
Andre time where repaint() worked (better), although I doubt that
Andre reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?

JMarc

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

Andre == Andre Poenitz [EMAIL PROTECTED] writes:


Andre There is indeed no reason (in theory) for us to use repaint().
Andre update() just does the right thing, possibly combining repeated
Andre request to a single one.

Andre In practivce, there might have been a reason at some point of
Andre time where repaint() worked (better), although I doubt that
Andre reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?


Michael Gerz tested it on windows where it made no harm. I am quite sure 
it would make no harm on any platform and it might help snappiness for 
low-end platform. I guess this is for 1.4.1. Attached the updated patch.


There is something I wonder about this repaint thing. In QContentPane.C, 
there is a kind of buffer for pressed keys (keyeventQueue_); IIRC that 
was introduced by Lars in order to improve snappiness whenever a user 
hold down the PageDown key or the Down key. It was also created to avoid 
occasional drop of chars.


http://thread.gmane.org/gmane.editors.lyx.devel/43381

In my qt4 port I have replaced all repaint calls with update and I 
have commented out this buffer machinery. The end result is very snappy 
and I don't see the effects described in the above thread.


Food for thought...

Abdel.




JMarc



Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()-repaint(
+   owner_.getContent()-update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   nocursor_pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   -repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   -update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Jean-Marc Lasgouttes a écrit :
Andre == Andre Poenitz 
[EMAIL PROTECTED] 
writes:


Andre There is indeed no reason (in theory) for us to use repaint().
Andre update() just does the right thing, possibly combining repeated
Andre request to a single one.

Andre In practivce, there might have been a reason at some point of
Andre time where repaint() worked (better), although I doubt that
Andre reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?


Michael Gerz tested it on windows where it made no harm. I am quite sure 
it would make no harm on any platform and it might help snappiness for 
low-end platform. I guess this is for 1.4.1. Attached the updated patch.


There is something I wonder about this repaint thing. In QContentPane.C, 
there is a kind of buffer for pressed keys (keyeventQueue_); IIRC that 
was introduced by Lars in order to improve snappiness whenever a user 
hold down the PageDown key or the Down key. It was also created to avoid 
occasional drop of chars.


http://thread.gmane.org/gmane.editors.lyx.devel/43381


Reading this thread, I see that the problem was mainly on MacOSX. If 
somebody is willing to test on this platform, I can provide a patch that 
will remove this key buffering in the qt2 frontend.




In my qt4 port I have replaced all repaint calls with update and I 
have commented out this buffer machinery. The end result is very snappy 
and I don't see the effects described in the above thread.


Food for thought...

Abdel.




JMarc






Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()-repaint(
+   owner_.getContent()-update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   nocursor_pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   -repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   -update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:

Reading this thread, I see that the problem was mainly on MacOSX.  
If somebody is willing to test on this platform, I can provide a  
patch that will remove this key buffering in the qt2 frontend.


That would be me: I'm happy to test.

Bennett

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Abdelrazak Younes wrote:

Michael Gerz tested it on windows where it made no harm. I am quite 
sure it would make no harm on any platform and it might help 
snappiness for low-end platform. I guess this is for 1.4.1. Attached 
the updated patch.



I can confirm that the patch does not hurt.

Abdel, should we put this patch into bugzilla or will you remember it on 
Feb 8th (day 1 after LyX 1.4.0)? :-)


Michael

RE: [Patch] (Re: Screen update improvements)

[YOUNES Abdelrazak \(M3SYSTEM\)]

Hello Bennett,

I'll send a patch tomorrow but you can already test if the patch I sent earlier 
has any impact on performance on MacOSX.

Abdel.


-Original Message-
From: Bennett Helm [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:39 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:

 Reading this thread, I see that the problem was mainly on MacOSX.  
 If somebody is willing to test on this platform, I can provide a  
 patch that will remove this key buffering in the qt2 frontend.

That would be me: I'm happy to test.

Bennett




This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.

RE: [Patch] (Re: Screen update improvements)

[YOUNES Abdelrazak \(M3SYSTEM\)]

-Original Message-
From: Michael Gerz [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:54 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
Abdelrazak Younes wrote:

 Michael Gerz tested it on windows where it made no harm. I am quite 
 sure it would make no harm on any platform and it might help 
 snappiness for low-end platform. I guess this is for 1.4.1. Attached 
 the updated patch.


Michael I can confirm that the patch does not hurt.

You tested on linux and Windows right?

Michael Abdel, should we put this patch into bugzilla or will you 
Michael remember it on Feb 8th (day 1 after LyX 1.4.0)? :-)

The gmane news interface will remember this for me but feel free to add it to 
bugzilla if there is an entry for that.

Abdel.

Michael





This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> There is indeed no reason (in theory) for us to use repaint().
Andre> update() just does the right thing, possibly combining repeated
Andre> request to a single one.

Andre> In practivce, there might have been a reason at some point of
Andre> time where repaint() worked (better), although I doubt that
Andre> reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?

JMarc

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

"Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:


Andre> There is indeed no reason (in theory) for us to use repaint().
Andre> update() just does the right thing, possibly combining repeated
Andre> request to a single one.

Andre> In practivce, there might have been a reason at some point of
Andre> time where repaint() worked (better), although I doubt that
Andre> reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?


Michael Gerz tested it on windows where it made no harm. I am quite sure 
it would make no harm on any platform and it might help "snappiness" for 
low-end platform. I guess this is for 1.4.1. Attached the updated patch.


There is something I wonder about this repaint thing. In QContentPane.C, 
there is a kind of buffer for pressed keys (keyeventQueue_); IIRC that 
was introduced by Lars in order to improve snappiness whenever a user 
hold down the PageDown key or the Down key. It was also created to avoid 
"occasional drop of chars".


http://thread.gmane.org/gmane.editors.lyx.devel/43381

In my qt4 port I have replaced all "repaint" calls with "update" and I 
have commented out this buffer machinery. The end result is very snappy 
and I don't see the effects described in the above thread.


Food for thought...

Abdel.




JMarc



Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()->repaint(
+   owner_.getContent()->update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   _pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   ->repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   ->update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Jean-Marc Lasgouttes a écrit :
"Andre" == Andre Poenitz 
<[EMAIL PROTECTED]> 
writes:


Andre> There is indeed no reason (in theory) for us to use repaint().
Andre> update() just does the right thing, possibly combining repeated
Andre> request to a single one.

Andre> In practivce, there might have been a reason at some point of
Andre> time where repaint() worked (better), although I doubt that
Andre> reason is still valid.

What happened to this patch? Did we decide something about it? Does it
help in some cases?


Michael Gerz tested it on windows where it made no harm. I am quite sure 
it would make no harm on any platform and it might help "snappiness" for 
low-end platform. I guess this is for 1.4.1. Attached the updated patch.


There is something I wonder about this repaint thing. In QContentPane.C, 
there is a kind of buffer for pressed keys (keyeventQueue_); IIRC that 
was introduced by Lars in order to improve snappiness whenever a user 
hold down the PageDown key or the Down key. It was also created to avoid 
"occasional drop of chars".


http://thread.gmane.org/gmane.editors.lyx.devel/43381


Reading this thread, I see that the problem was mainly on MacOSX. If 
somebody is willing to test on this platform, I can provide a patch that 
will remove this key buffering in the qt2 frontend.




In my qt4 port I have replaced all "repaint" calls with "update" and I 
have commented out this buffer machinery. The end result is very snappy 
and I don't see the effects described in the above thread.


Food for thought...

Abdel.




JMarc






Index: qscreen.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v
retrieving revision 1.29
diff -u -r1.29 qscreen.C
--- qscreen.C   19 May 2005 16:34:02 -  1.29
+++ qscreen.C   24 Jan 2006 16:14:34 -
@@ -144,7 +144,7 @@
break;
}

-   owner_.getContent()->repaint(
+   owner_.getContent()->update(
cursor_x_, cursor_y_,
cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@
   _pixmap_, 0, 0, cursor_w_, cursor_h_);

owner_.getContent()
-   ->repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+   ->update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:

Reading this thread, I see that the problem was mainly on MacOSX.  
If somebody is willing to test on this platform, I can provide a  
patch that will remove this key buffering in the qt2 frontend.


That would be me: I'm happy to test.

Bennett

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Abdelrazak Younes wrote:

Michael Gerz tested it on windows where it made no harm. I am quite 
sure it would make no harm on any platform and it might help 
"snappiness" for low-end platform. I guess this is for 1.4.1. Attached 
the updated patch.



I can confirm that the patch does not hurt.

Abdel, should we put this patch into bugzilla or will you remember it on 
Feb 8th (day 1 after LyX 1.4.0)? :-)


Michael

RE: [Patch] (Re: Screen update improvements)

[YOUNES Abdelrazak \(M3SYSTEM\)]

Hello Bennett,

I'll send a patch tomorrow but you can already test if the patch I sent earlier 
has any impact on performance on MacOSX.

Abdel.


-Original Message-
From: Bennett Helm [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:39 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
On Jan 24, 2006, at 12:14 PM, Abdelrazak Younes wrote:

> Reading this thread, I see that the problem was mainly on MacOSX.  
> If somebody is willing to test on this platform, I can provide a  
> patch that will remove this key buffering in the qt2 frontend.

That would be me: I'm happy to test.

Bennett




This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.

RE: [Patch] (Re: Screen update improvements)

[YOUNES Abdelrazak \(M3SYSTEM\)]

-Original Message-
From: Michael Gerz [mailto:[EMAIL PROTECTED]
Sent: Tue 1/24/2006 7:54 PM
To: YOUNES Abdelrazak (M3SYSTEM)
Cc: lyx-devel@lists.lyx.org
Subject: Re: [Patch] (Re: Screen update improvements)
 
Abdelrazak Younes wrote:

> Michael Gerz tested it on windows where it made no harm. I am quite 
> sure it would make no harm on any platform and it might help 
> "snappiness" for low-end platform. I guess this is for 1.4.1. Attached 
> the updated patch.
>

Michael> I can confirm that the patch does not hurt.

You tested on linux and Windows right?

Michael> Abdel, should we put this patch into bugzilla or will you 
Michael> remember it on Feb 8th (day 1 after LyX 1.4.0)? :-)

The gmane news interface will remember this for me but feel free to add it to 
bugzilla if there is an entry for that.

Abdel.

Michael





This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Lars Gullik Bjønnes a écrit :

Abdel [EMAIL PROTECTED] writes:

| Martin Vermeer a écrit :
|  On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
|  Abdel wrote:
| 
|  About the flickering, I don't know. You could verify with my earlier
|  published PAINTING debug patch, precisely which rows are getting
|  updated by the LyX painter.
|  AFAIK, this flickering is not due to lyx internal repainting (i.e
|  to the pixmap) but to the screen update. What Michael sees is a
|  background repaint immediately followed by the pixmap repaint on
|  screen. And this is what my simple patch is fixing (as advised by
|  Jean-Marc) by eliminating the superfluous background repainting.
| 
|  Hum, actually I think there might be another reason. Michael,
|  could you please try this patch:
| 
|  Index: qscreen.C
|  ===
| 
|  -   owner_.getContent()-repaint(
|  +   owner_.getContent()-update(
|  Abdel, Martin,
| 
|  I must confess that I am a bit puzzled. If I understand correctly,
|  it doesn't matter how clever we are as long as the background is
|  repainted every time.
| 
|  Maybe these results will help you to sort out things:
| 
|  1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday),
|  the flickering occurs with every character insertion/deletion and
|  text selection but not when moving the cursor.
|  2. With the additional simple QWorkarea.C patch proposed by J-M, I
|  see no flickering at all (even without Martin's recent patch
|  proposals)
|  3. With the above qscreen.C patch (as an alternative to 2.), the
|  flickering is still there. (It also doesn't help to also replace
|  repaint by update in method removeCursor)
| 
|  AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you
|  to draw the final conclusion. Do we loose anything if we change
|  QWorkarea.C?
| 
|  Thank you very much for all the efforts in advance! You make people
|  really happy!
| 
|  Michael
|  Yes, I agree... I think flicker and speed are orthogonal
|  problems.
|  The fact that cursor movement doesn't produce flicker is because then
|  there literally is no screen update.
|  - Martin
| 
| Yep and IMHO the no-background change is a must for windows. If it

| doesn't change anything under linux and Mac (it shouldn't) let it be
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around
| it.

What I think is that changes like these are too late for 1.4.0.

But we expect 1.4.1 do be done fairly quick after 1.4.0 is released.


No problem but make sure that this is said in the announcement for 1.4.0 
- i.e: Windows user should not upgrade to 1.4.0 but wait for 1.4.1.


Thanks,
Abdel.

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

| Yep and IMHO the no-background change is a must for windows. If it 
| doesn't change anything under linux and Mac (it shouldn't) let it be 
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around 
| it.

Lars What I think is that changes like these are too late for 1.4.0.

Yes. Nevertheless I would like these patch to get good testing.
Bennett, could you try to apply the noflicker patch to LyX/Mac and see
what it does?

I put it in the new bug
http://bugzilla.lyx.org/show_bug.cgi?id=2197

JMarc

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

 Abdel == Abdel  [EMAIL PROTECTED] writes:

Abdel Hum, actually I think there might be another reason. Michael,
Abdel could you please try this patch:

This seems quite interesting. Do you have reasons to think it should
help, or is it just that it looks nicer?

JMarc

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Jean-Marc Lasgouttes a écrit :

Abdel == Abdel  [EMAIL PROTECTED] writes:


Abdel Hum, actually I think there might be another reason. Michael,
Abdel could you please try this patch:

This seems quite interesting. Do you have reasons to think it should
help, or is it just that it looks nicer?


I think it should help definitely this use case: someone who keep an 
arrow key pressed in order to move within the text. This is because, the 
problem with the repaint function is that it ask Qt to repaint 
immediately. So multiply that by the autorepeat settings of some desktop 
that could be very high for some people and I guess that the end result 
is an unresponsive application.


This is just a guess, I haven't read the Cursor code in detail.

Abdel.




JMarc

Re: [Patch] (Re: Screen update improvements)

[Andre Poenitz]

On Mon, Jan 09, 2006 at 10:39:30AM +0100, Abdel wrote:
 Jean-Marc Lasgouttes a écrit :
 Abdel == Abdel  [EMAIL PROTECTED] writes:
 
 Abdel Hum, actually I think there might be another reason. Michael,
 Abdel could you please try this patch:
 
 This seems quite interesting. Do you have reasons to think it should
 help, or is it just that it looks nicer?
 
 I think it should help definitely this use case: someone who keep an 
 arrow key pressed in order to move within the text. This is because, the 
 problem with the repaint function is that it ask Qt to repaint 
 immediately. So multiply that by the autorepeat settings of some desktop 
 that could be very high for some people and I guess that the end result 
 is an unresponsive application.

There is indeed no reason (in theory) for us to use repaint(). update()
just does the right thing, possibly combining repeated request to a
single one. 

In practivce, there might have been a reason at some point of time where
repaint() worked (better), although I doubt that reason is still valid.

Andre'

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 9, 2006, at 4:28 AM, Jean-Marc Lasgouttes wrote:


Bennett, could you try to apply the noflicker patch to LyX/Mac and see
what it does?


I would if I could ... but I still can't link. (http://www.mail- 
archive.com/lyx-devel@lists.lyx.org/msg84546.html)


Bennett

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Lars Gullik Bjønnes a écrit :

Abdel <[EMAIL PROTECTED]> writes:

| Martin Vermeer a écrit :
| > On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
| >> Abdel wrote:
| >>
| > About the flickering, I don't know. You could verify with my earlier
| > published PAINTING debug patch, precisely which rows are getting
| > updated by the LyX painter.
|  AFAIK, this flickering is not due to lyx internal repainting (i.e
|  to the pixmap) but to the screen update. What Michael sees is a
|  background repaint immediately followed by the pixmap repaint on
|  screen. And this is what my simple patch is fixing (as advised by
|  Jean-Marc) by eliminating the superfluous background repainting.
| >>>
| >>> Hum, actually I think there might be another reason. Michael,
| >>> could you please try this patch:
| >>>
| >>> Index: qscreen.C
| >>> ===
| >>>
| >>> -   owner_.getContent()->repaint(
| >>> +   owner_.getContent()->update(
| >> Abdel, Martin,
| >>
| >> I must confess that I am a bit puzzled. If I understand correctly,
| >> it doesn't matter how clever we are as long as the background is
| >> repainted every time.
| >>
| >> Maybe these results will help you to sort out things:
| >>
| >> 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday),
| >> the flickering occurs with every character insertion/deletion and
| >> text selection but not when moving the cursor.
| >> 2. With the additional simple QWorkarea.C patch proposed by J-M, I
| >> see no flickering at all (even without Martin's recent patch
| >> proposals)
| >> 3. With the above qscreen.C patch (as an alternative to 2.), the
| >> flickering is still there. (It also doesn't help to also replace
| >> "repaint" by "update" in method removeCursor)
| >>
| >> AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you
| >> to draw the final conclusion. Do we loose anything if we change
| >> QWorkarea.C?
| >>
| >> Thank you very much for all the efforts in advance! You make people
| >> really happy!
| >>
| >> Michael
| > Yes, I agree... I think "flicker" and "speed" are orthogonal
| > problems.
| > The fact that cursor movement doesn't produce flicker is because then
| > there literally is no screen update.
| > - Martin
| 
| Yep and IMHO the no-background change is a must for windows. If it

| doesn't change anything under linux and Mac (it shouldn't) let it be
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around
| it.

What I think is that changes like these are too late for 1.4.0.

But we expect 1.4.1 do be done fairly quick after 1.4.0 is released.


No problem but make sure that this is said in the announcement for 1.4.0 
- i.e: Windows user should not upgrade to 1.4.0 but wait for 1.4.1.


Thanks,
Abdel.

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| Yep and IMHO the no-background change is a must for windows. If it 
| doesn't change anything under linux and Mac (it shouldn't) let it be 
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around 
| it.

Lars> What I think is that changes like these are too late for 1.4.0.

Yes. Nevertheless I would like these patch to get good testing.
Bennett, could you try to apply the noflicker patch to LyX/Mac and see
what it does?

I put it in the new bug
http://bugzilla.lyx.org/show_bug.cgi?id=2197

JMarc

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

> "Abdel" == Abdel  <[EMAIL PROTECTED]> writes:

Abdel> Hum, actually I think there might be another reason. Michael,
Abdel> could you please try this patch:

This seems quite interesting. Do you have reasons to think it should
help, or is it just that it looks nicer?

JMarc

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Jean-Marc Lasgouttes a écrit :

"Abdel" == Abdel  <[EMAIL PROTECTED]> writes:


Abdel> Hum, actually I think there might be another reason. Michael,
Abdel> could you please try this patch:

This seems quite interesting. Do you have reasons to think it should
help, or is it just that it looks nicer?


I think it should help definitely this use case: someone who keep an 
arrow key pressed in order to move within the text. This is because, the 
problem with the "repaint" function is that it ask Qt to repaint 
immediately. So multiply that by the autorepeat settings of some desktop 
that could be very high for some people and I guess that the end result 
is an unresponsive application.


This is just a guess, I haven't read the Cursor code in detail.

Abdel.




JMarc

Re: [Patch] (Re: Screen update improvements)

[Andre Poenitz]

On Mon, Jan 09, 2006 at 10:39:30AM +0100, Abdel wrote:
> Jean-Marc Lasgouttes a écrit :
> >>"Abdel" == Abdel  <[EMAIL PROTECTED]> writes:
> >
> >Abdel> Hum, actually I think there might be another reason. Michael,
> >Abdel> could you please try this patch:
> >
> >This seems quite interesting. Do you have reasons to think it should
> >help, or is it just that it looks nicer?
> 
> I think it should help definitely this use case: someone who keep an 
> arrow key pressed in order to move within the text. This is because, the 
> problem with the "repaint" function is that it ask Qt to repaint 
> immediately. So multiply that by the autorepeat settings of some desktop 
> that could be very high for some people and I guess that the end result 
> is an unresponsive application.

There is indeed no reason (in theory) for us to use repaint(). update()
just does the right thing, possibly combining repeated request to a
single one. 

In practivce, there might have been a reason at some point of time where
repaint() worked (better), although I doubt that reason is still valid.

Andre'

Re: [Patch] (Re: Screen update improvements)

[Bennett Helm]

On Jan 9, 2006, at 4:28 AM, Jean-Marc Lasgouttes wrote:


Bennett, could you try to apply the noflicker patch to LyX/Mac and see
what it does?


I would if I could ... but I still can't link. ()


Bennett

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Martin Vermeer wrote:


Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no turds or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.
 


Dear Martin,

using qtwin on Windows, I cannot see any difference. The flickering 
still occurs even if I select text in a single row. (BTW: The best way 
to cause flickering is editing a short document that does not cover the 
full screen; you can see easily how the gray background at the bottom 
flickers).


Another thing that astonishes me: Why do we have to do a full redraw if 
a single character is inserted/deleted? It shouldn't be necessary in 
most cases.


Michael

Re: [Patch] (Re: Screen update improvements)

[Martin Vermeer]

On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote:
 Martin Vermeer wrote:
 
 
 using qtwin on Windows, I cannot see any difference. The flickering 
 still occurs even if I select text in a single row. (BTW: The best way 
 to cause flickering is editing a short document that does not cover the 
 full screen; you can see easily how the gray background at the bottom 
 flickers).
 
 Another thing that astonishes me: Why do we have to do a full redraw if 
 a single character is inserted/deleted? It shouldn't be necessary in 
 most cases.

With an updated tree you shouldn't see _any_ full-screen update for
typing characters generally, except occasionally when you cause a
rebreak that changes paragraph height. Otherwise only the current
paragraph should refresh.

About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.

Did the patch apply cleanly? That means you must have the singlepar
stuff in your local tree... strange.

- Martin



pgpehWsniBGeE.pgp
Description: PGP signature

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Martin Vermeer a écrit :

On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote:

Martin Vermeer wrote:
 
 
using qtwin on Windows, I cannot see any difference. The flickering 
still occurs even if I select text in a single row. (BTW: The best way 
to cause flickering is editing a short document that does not cover the 
full screen; you can see easily how the gray background at the bottom 
flickers).


Another thing that astonishes me: Why do we have to do a full redraw if 
a single character is inserted/deleted? It shouldn't be necessary in 
most cases.


With an updated tree you shouldn't see _any_ full-screen update for
typing characters generally, except occasionally when you cause a
rebreak that changes paragraph height. Otherwise only the current
paragraph should refresh.

About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.


AFAIK, this flickering is not due to lyx internal repainting (i.e to the 
pixmap) but to the screen update. What Michael sees is a background 
repaint immediately followed by the pixmap repaint on screen. And this 
is what my simple patch is fixing (as advised by Jean-Marc) by 
eliminating the superfluous background repainting.


Abdel.




Did the patch apply cleanly? That means you must have the singlepar
stuff in your local tree... strange.

- Martin

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Abdel wrote:


About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.


AFAIK, this flickering is not due to lyx internal repainting (i.e to 
the pixmap) but to the screen update. What Michael sees is a 
background repaint immediately followed by the pixmap repaint on 
screen. And this is what my simple patch is fixing (as advised by 
Jean-Marc) by eliminating the superfluous background repainting.



Hum, actually I think there might be another reason. Michael, could 
you please try this patch:


Index: qscreen.C
===

-   owner_.getContent()-repaint(
+   owner_.getContent()-update(


Abdel, Martin,

I must confess that I am a bit puzzled. If I understand correctly, it 
doesn't matter how clever we are as long as the background is repainted 
every time.


Maybe these results will help you to sort out things:

1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
flickering occurs with every character insertion/deletion and text 
selection but not when moving the cursor.
2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
no flickering at all (even without Martin's recent patch proposals)
3. With the above qscreen.C patch (as an alternative to 2.), the 
flickering is still there. (It also doesn't help to also replace 
repaint by update in method removeCursor)


AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
draw the final conclusion. Do we loose anything if we change QWorkarea.C?


Thank you very much for all the efforts in advance! You make people 
really happy!


Michael

Re: [Patch] (Re: Screen update improvements)

[Martin Vermeer]

On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
 Abdel wrote:
 
 About the flickering, I don't know. You could verify with my earlier
 published PAINTING debug patch, precisely which rows are getting
 updated by the LyX painter.
 
 AFAIK, this flickering is not due to lyx internal repainting (i.e to 
 the pixmap) but to the screen update. What Michael sees is a 
 background repaint immediately followed by the pixmap repaint on 
 screen. And this is what my simple patch is fixing (as advised by 
 Jean-Marc) by eliminating the superfluous background repainting.
 
 
 Hum, actually I think there might be another reason. Michael, could 
 you please try this patch:
 
 Index: qscreen.C
 ===
 
 -   owner_.getContent()-repaint(
 +   owner_.getContent()-update(
 
 Abdel, Martin,
 
 I must confess that I am a bit puzzled. If I understand correctly, it 
 doesn't matter how clever we are as long as the background is repainted 
 every time.
 
 Maybe these results will help you to sort out things:
 
 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
 flickering occurs with every character insertion/deletion and text 
 selection but not when moving the cursor.
 2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
 no flickering at all (even without Martin's recent patch proposals)
 3. With the above qscreen.C patch (as an alternative to 2.), the 
 flickering is still there. (It also doesn't help to also replace 
 repaint by update in method removeCursor)
 
 AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
 draw the final conclusion. Do we loose anything if we change QWorkarea.C?
 
 Thank you very much for all the efforts in advance! You make people 
 really happy!
 
 Michael

Yes, I agree... I think flicker and speed are orthogonal problems.

The fact that cursor movement doesn't produce flicker is because then
there literally is no screen update.

- Martin



pgp04DDS7kDzb.pgp
Description: PGP signature

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Martin Vermeer a écrit :

On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:

Abdel wrote:


About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.
AFAIK, this flickering is not due to lyx internal repainting (i.e to 
the pixmap) but to the screen update. What Michael sees is a 
background repaint immediately followed by the pixmap repaint on 
screen. And this is what my simple patch is fixing (as advised by 
Jean-Marc) by eliminating the superfluous background repainting.


Hum, actually I think there might be another reason. Michael, could 
you please try this patch:


Index: qscreen.C
===

-   owner_.getContent()-repaint(
+   owner_.getContent()-update(

Abdel, Martin,

I must confess that I am a bit puzzled. If I understand correctly, it 
doesn't matter how clever we are as long as the background is repainted 
every time.


Maybe these results will help you to sort out things:

1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
flickering occurs with every character insertion/deletion and text 
selection but not when moving the cursor.
2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
no flickering at all (even without Martin's recent patch proposals)
3. With the above qscreen.C patch (as an alternative to 2.), the 
flickering is still there. (It also doesn't help to also replace 
repaint by update in method removeCursor)


AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
draw the final conclusion. Do we loose anything if we change QWorkarea.C?


Thank you very much for all the efforts in advance! You make people 
really happy!


Michael


Yes, I agree... I think flicker and speed are orthogonal problems.

The fact that cursor movement doesn't produce flicker is because then
there literally is no screen update.

- Martin


Yep and IMHO the no-background change is a must for windows. If it 
doesn't change anything under linux and Mac (it shouldn't) let it be in. 
If you think it's a risk, put an #ifdef QT_WIN and #endif around it.


Abdel.

Re: [Patch] (Re: Screen update improvements)

[Lars Gullik Bjønnes]

Abdel [EMAIL PROTECTED] writes:

| Martin Vermeer a écrit :
|  On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
|  Abdel wrote:
| 
|  About the flickering, I don't know. You could verify with my earlier
|  published PAINTING debug patch, precisely which rows are getting
|  updated by the LyX painter.
|  AFAIK, this flickering is not due to lyx internal repainting (i.e
|  to the pixmap) but to the screen update. What Michael sees is a
|  background repaint immediately followed by the pixmap repaint on
|  screen. And this is what my simple patch is fixing (as advised by
|  Jean-Marc) by eliminating the superfluous background repainting.
| 
|  Hum, actually I think there might be another reason. Michael,
|  could you please try this patch:
| 
|  Index: qscreen.C
|  ===
| 
|  -   owner_.getContent()-repaint(
|  +   owner_.getContent()-update(
|  Abdel, Martin,
| 
|  I must confess that I am a bit puzzled. If I understand correctly,
|  it doesn't matter how clever we are as long as the background is
|  repainted every time.
| 
|  Maybe these results will help you to sort out things:
| 
|  1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday),
|  the flickering occurs with every character insertion/deletion and
|  text selection but not when moving the cursor.
|  2. With the additional simple QWorkarea.C patch proposed by J-M, I
|  see no flickering at all (even without Martin's recent patch
|  proposals)
|  3. With the above qscreen.C patch (as an alternative to 2.), the
|  flickering is still there. (It also doesn't help to also replace
|  repaint by update in method removeCursor)
| 
|  AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you
|  to draw the final conclusion. Do we loose anything if we change
|  QWorkarea.C?
| 
|  Thank you very much for all the efforts in advance! You make people
|  really happy!
| 
|  Michael
|  Yes, I agree... I think flicker and speed are orthogonal
|  problems.
|  The fact that cursor movement doesn't produce flicker is because then
|  there literally is no screen update.
|  - Martin
| 
| Yep and IMHO the no-background change is a must for windows. If it
| doesn't change anything under linux and Mac (it shouldn't) let it be
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around
| it.

What I think is that changes like these are too late for 1.4.0.

But we expect 1.4.1 do be done fairly quick after 1.4.0 is released.

-- 
Lgb

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Martin Vermeer wrote:


Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no "turds" or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.
 


Dear Martin,

using qtwin on Windows, I cannot see any difference. The flickering 
still occurs even if I select text in a single row. (BTW: The best way 
to cause flickering is editing a short document that does not cover the 
full screen; you can see easily how the gray background at the bottom 
flickers).


Another thing that astonishes me: Why do we have to do a full redraw if 
a single character is inserted/deleted? It shouldn't be necessary in 
most cases.


Michael

Re: [Patch] (Re: Screen update improvements)

[Martin Vermeer]

On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote:
> Martin Vermeer wrote:
 
 
> using qtwin on Windows, I cannot see any difference. The flickering 
> still occurs even if I select text in a single row. (BTW: The best way 
> to cause flickering is editing a short document that does not cover the 
> full screen; you can see easily how the gray background at the bottom 
> flickers).
> 
> Another thing that astonishes me: Why do we have to do a full redraw if 
> a single character is inserted/deleted? It shouldn't be necessary in 
> most cases.

With an updated tree you shouldn't see _any_ full-screen update for
typing characters generally, except occasionally when you cause a
rebreak that changes paragraph height. Otherwise only the current
paragraph should refresh.

About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.

Did the patch apply cleanly? That means you must have the singlepar
stuff in your local tree... strange.

- Martin



pgpehWsniBGeE.pgp
Description: PGP signature

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Martin Vermeer a écrit :

On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote:

Martin Vermeer wrote:
 
 
using qtwin on Windows, I cannot see any difference. The flickering 
still occurs even if I select text in a single row. (BTW: The best way 
to cause flickering is editing a short document that does not cover the 
full screen; you can see easily how the gray background at the bottom 
flickers).


Another thing that astonishes me: Why do we have to do a full redraw if 
a single character is inserted/deleted? It shouldn't be necessary in 
most cases.


With an updated tree you shouldn't see _any_ full-screen update for
typing characters generally, except occasionally when you cause a
rebreak that changes paragraph height. Otherwise only the current
paragraph should refresh.

About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.


AFAIK, this flickering is not due to lyx internal repainting (i.e to the 
pixmap) but to the screen update. What Michael sees is a background 
repaint immediately followed by the pixmap repaint on screen. And this 
is what my simple patch is fixing (as advised by Jean-Marc) by 
eliminating the superfluous background repainting.


Abdel.




Did the patch apply cleanly? That means you must have the singlepar
stuff in your local tree... strange.

- Martin

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Abdel wrote:


About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.


AFAIK, this flickering is not due to lyx internal repainting (i.e to 
the pixmap) but to the screen update. What Michael sees is a 
background repaint immediately followed by the pixmap repaint on 
screen. And this is what my simple patch is fixing (as advised by 
Jean-Marc) by eliminating the superfluous background repainting.



Hum, actually I think there might be another reason. Michael, could 
you please try this patch:


Index: qscreen.C
===

-   owner_.getContent()->repaint(
+   owner_.getContent()->update(


Abdel, Martin,

I must confess that I am a bit puzzled. If I understand correctly, it 
doesn't matter how clever we are as long as the background is repainted 
every time.


Maybe these results will help you to sort out things:

1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
flickering occurs with every character insertion/deletion and text 
selection but not when moving the cursor.
2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
no flickering at all (even without Martin's recent patch proposals)
3. With the above qscreen.C patch (as an alternative to 2.), the 
flickering is still there. (It also doesn't help to also replace 
"repaint" by "update" in method removeCursor)


AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
draw the final conclusion. Do we loose anything if we change QWorkarea.C?


Thank you very much for all the efforts in advance! You make people 
really happy!


Michael

Re: [Patch] (Re: Screen update improvements)

[Martin Vermeer]

On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
> Abdel wrote:
> 
> >>>About the flickering, I don't know. You could verify with my earlier
> >>>published PAINTING debug patch, precisely which rows are getting
> >>>updated by the LyX painter.
> >>
> >>AFAIK, this flickering is not due to lyx internal repainting (i.e to 
> >>the pixmap) but to the screen update. What Michael sees is a 
> >>background repaint immediately followed by the pixmap repaint on 
> >>screen. And this is what my simple patch is fixing (as advised by 
> >>Jean-Marc) by eliminating the superfluous background repainting.
> >
> >
> >Hum, actually I think there might be another reason. Michael, could 
> >you please try this patch:
> >
> >Index: qscreen.C
> >===
> >
> >-   owner_.getContent()->repaint(
> >+   owner_.getContent()->update(
> 
> Abdel, Martin,
> 
> I must confess that I am a bit puzzled. If I understand correctly, it 
> doesn't matter how clever we are as long as the background is repainted 
> every time.
> 
> Maybe these results will help you to sort out things:
> 
> 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
> flickering occurs with every character insertion/deletion and text 
> selection but not when moving the cursor.
> 2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
> no flickering at all (even without Martin's recent patch proposals)
> 3. With the above qscreen.C patch (as an alternative to 2.), the 
> flickering is still there. (It also doesn't help to also replace 
> "repaint" by "update" in method removeCursor)
> 
> AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
> draw the final conclusion. Do we loose anything if we change QWorkarea.C?
> 
> Thank you very much for all the efforts in advance! You make people 
> really happy!
> 
> Michael

Yes, I agree... I think "flicker" and "speed" are orthogonal problems.

The fact that cursor movement doesn't produce flicker is because then
there literally is no screen update.

- Martin



pgp04DDS7kDzb.pgp
Description: PGP signature

Re: [Patch] (Re: Screen update improvements)

[Abdel]

Martin Vermeer a écrit :

On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:

Abdel wrote:


About the flickering, I don't know. You could verify with my earlier
published PAINTING debug patch, precisely which rows are getting
updated by the LyX painter.
AFAIK, this flickering is not due to lyx internal repainting (i.e to 
the pixmap) but to the screen update. What Michael sees is a 
background repaint immediately followed by the pixmap repaint on 
screen. And this is what my simple patch is fixing (as advised by 
Jean-Marc) by eliminating the superfluous background repainting.


Hum, actually I think there might be another reason. Michael, could 
you please try this patch:


Index: qscreen.C
===

-   owner_.getContent()->repaint(
+   owner_.getContent()->update(

Abdel, Martin,

I must confess that I am a bit puzzled. If I understand correctly, it 
doesn't matter how clever we are as long as the background is repainted 
every time.


Maybe these results will help you to sort out things:

1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the 
flickering occurs with every character insertion/deletion and text 
selection but not when moving the cursor.
2. With the additional simple QWorkarea.C patch proposed by J-M, I see 
no flickering at all (even without Martin's recent patch proposals)
3. With the above qscreen.C patch (as an alternative to 2.), the 
flickering is still there. (It also doesn't help to also replace 
"repaint" by "update" in method removeCursor)


AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to 
draw the final conclusion. Do we loose anything if we change QWorkarea.C?


Thank you very much for all the efforts in advance! You make people 
really happy!


Michael


Yes, I agree... I think "flicker" and "speed" are orthogonal problems.

The fact that cursor movement doesn't produce flicker is because then
there literally is no screen update.

- Martin


Yep and IMHO the no-background change is a must for windows. If it 
doesn't change anything under linux and Mac (it shouldn't) let it be in. 
If you think it's a risk, put an #ifdef QT_WIN and #endif around it.


Abdel.

Re: [Patch] (Re: Screen update improvements)

[Lars Gullik Bjønnes]

Abdel <[EMAIL PROTECTED]> writes:

| Martin Vermeer a écrit :
| > On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote:
| >> Abdel wrote:
| >>
| > About the flickering, I don't know. You could verify with my earlier
| > published PAINTING debug patch, precisely which rows are getting
| > updated by the LyX painter.
|  AFAIK, this flickering is not due to lyx internal repainting (i.e
|  to the pixmap) but to the screen update. What Michael sees is a
|  background repaint immediately followed by the pixmap repaint on
|  screen. And this is what my simple patch is fixing (as advised by
|  Jean-Marc) by eliminating the superfluous background repainting.
| >>>
| >>> Hum, actually I think there might be another reason. Michael,
| >>> could you please try this patch:
| >>>
| >>> Index: qscreen.C
| >>> ===
| >>>
| >>> -   owner_.getContent()->repaint(
| >>> +   owner_.getContent()->update(
| >> Abdel, Martin,
| >>
| >> I must confess that I am a bit puzzled. If I understand correctly,
| >> it doesn't matter how clever we are as long as the background is
| >> repainted every time.
| >>
| >> Maybe these results will help you to sort out things:
| >>
| >> 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday),
| >> the flickering occurs with every character insertion/deletion and
| >> text selection but not when moving the cursor.
| >> 2. With the additional simple QWorkarea.C patch proposed by J-M, I
| >> see no flickering at all (even without Martin's recent patch
| >> proposals)
| >> 3. With the above qscreen.C patch (as an alternative to 2.), the
| >> flickering is still there. (It also doesn't help to also replace
| >> "repaint" by "update" in method removeCursor)
| >>
| >> AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you
| >> to draw the final conclusion. Do we loose anything if we change
| >> QWorkarea.C?
| >>
| >> Thank you very much for all the efforts in advance! You make people
| >> really happy!
| >>
| >> Michael
| > Yes, I agree... I think "flicker" and "speed" are orthogonal
| > problems.
| > The fact that cursor movement doesn't produce flicker is because then
| > there literally is no screen update.
| > - Martin
| 
| Yep and IMHO the no-background change is a must for windows. If it
| doesn't change anything under linux and Mac (it shouldn't) let it be
| in. If you think it's a risk, put an #ifdef QT_WIN and #endif around
| it.

What I think is that changes like these are too late for 1.4.0.

But we expect 1.4.1 do be done fairly quick after 1.4.0 is released.

-- 
Lgb

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

 Michael == Michael Gerz [EMAIL PROTECTED] writes:

Michael I think we have to speed up selections and reduce flickering
Michael for 1.4.0. Right now, it is not a great joy to select text if
Michael the LyX windows covers the full screen.

Could you test the small patch posted by Abdel? I am curious to see
whether it helps on qt/win 3.

JMarc

Re: [Patch] (Re: Screen update improvements)

[Jean-Marc Lasgouttes]

> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> I think we have to speed up selections and reduce flickering
Michael> for 1.4.0. Right now, it is not a great joy to select text if
Michael> the LyX windows covers the full screen.

Could you test the small patch posted by Abdel? I am curious to see
whether it helps on qt/win 3.

JMarc

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Martin Vermeer wrote:

Could you please remove the conditions? I don't feel authorized to do so 
by myself... :-)
   



Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no turds or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.
 


I will do some testing tomorrow evening.

I think we have to speed up selections and reduce flickering for 1.4.0. 
Right now, it is not a great joy to select text if the LyX windows 
covers the full screen.


Michael

Re: [Patch] (Re: Screen update improvements)

[Michael Gerz]

Martin Vermeer wrote:

Could you please remove the conditions? I don't feel authorized to do so 
by myself... :-)
   



Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no "turds" or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.
 


I will do some testing tomorrow evening.

I think we have to speed up selections and reduce flickering for 1.4.0. 
Right now, it is not a great joy to select text if the LyX windows 
covers the full screen.


Michael