Re: [patch] sometimes only paragraph of cursor is visible, #3231
Alfredo Braunstein wrote: Abdelrazak Younes wrote: NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a Cursor thing. ScreenUpdateStrategy should be only about screen updating, so it's a frontend thing and BufferView make the link between the two. I introduced ScreenUpdateStrategy in order to cope with the decoration update case. I agree there's some confusion there though; we can revisite that field in 1.6 when we cleanup the rowpainter. I think that the question is rather: Why are we using NoScreenUpdate for painting stuff? ;-) Hum... actually we don't ;-) NoScreenUpdate is just a way to reset the ScreenUpdateStrategy. Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a Cursor thing. ScreenUpdateStrategy should be only about screen updating, so it's a frontend thing and BufferView make the link between the two. I introduced ScreenUpdateStrategy in order to cope with the decoration update case. I agree there's some confusion there though; we can revisite that field in 1.6 when we cleanup the rowpainter. I think that the question is rather: Why are we using NoScreenUpdate for painting stuff? ;-) Hum... actually we don't ;-) NoScreenUpdate is just a way to reset the ScreenUpdateStrategy. If we really aren't, then the patch from Stefan (at the top of this thread) shouldn't make any difference. But it does. A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Alfredo Braunstein wrote: Abdelrazak Younes wrote: NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a Cursor thing. ScreenUpdateStrategy should be only about screen updating, so it's a frontend thing and BufferView make the link between the two. I introduced ScreenUpdateStrategy in order to cope with the decoration update case. I agree there's some confusion there though; we can revisite that field in 1.6 when we cleanup the "rowpainter". I think that the question is rather: "Why are we using NoScreenUpdate for painting stuff?" ;-) Hum... actually we don't ;-) NoScreenUpdate is just a way to reset the ScreenUpdateStrategy. Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: > Alfredo Braunstein wrote: >> Abdelrazak Younes wrote: >> >>> NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a >>> Cursor thing. ScreenUpdateStrategy should be only about screen updating, >>> so it's a frontend thing and BufferView make the link between the two. I >>> introduced ScreenUpdateStrategy in order to cope with the decoration >>> update case. I agree there's some confusion there though; we can >>> revisite that field in 1.6 when we cleanup the "rowpainter". >> >> I think that the question is rather: "Why are we using NoScreenUpdate for >> painting stuff?" ;-) > > Hum... actually we don't ;-) > > NoScreenUpdate is just a way to reset the ScreenUpdateStrategy. If we really aren't, then the patch from Stefan (at the top of this thread) shouldn't make any difference. But it does. A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a Cursor thing. ScreenUpdateStrategy should be only about screen updating, so it's a frontend thing and BufferView make the link between the two. I introduced ScreenUpdateStrategy in order to cope with the decoration update case. I agree there's some confusion there though; we can revisite that field in 1.6 when we cleanup the rowpainter. I think that the question is rather: Why are we using NoScreenUpdate for painting stuff? ;-) A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: > NoUpdate and SingleParUpdate are about _text_ _metrics_ updating, its a > Cursor thing. ScreenUpdateStrategy should be only about screen updating, > so it's a frontend thing and BufferView make the link between the two. I > introduced ScreenUpdateStrategy in order to cope with the decoration > update case. I agree there's some confusion there though; we can > revisite that field in 1.6 when we cleanup the "rowpainter". I think that the question is rather: "Why are we using NoScreenUpdate for painting stuff?" ;-) A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Is it an OK? Have you tried it? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Alfredo Braunstein wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just return when vi.update_strategy == NoUpdate? And why are we calling paintText in the first place? The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Sorry if the questions don't make much sense, it's a long time I don't look at this part of the code... ;-) No surprise really because this part of the code has been rewritten since you left ;-) Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... No. :-) But I have not experienced this bug for a day after I applied the patch, so I guess the patch (and your analysis) is correct. Bo
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just return when vi.update_strategy == NoUpdate? And why are we calling paintText in the first place? The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Thanks, Alfredo
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Actually the redraw of text is _always_ from vi.y1 to vi.y2. The SingleParUpdate is only meant to signal that there are still other paragraphs on the screen which _should not_ be greyed out. IIRC and nobody has overhauled this code since ;-/ - Martin
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 10:04:28PM +0300, Martin Vermeer wrote: On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Actually the redraw of text is _always_ from vi.y1 to vi.y2. The SingleParUpdate is only meant to signal that there are still other paragraphs on the screen which _should not_ be greyed out. IIRC and nobody has overhauled this code since ;-/ Actually something seems to have happened... there is a bitstring func_attrib containing NoUpdate and SingleParUpdate as bits, in LyXAction.h; and then there is an enum ScreenUpdateStrategy also containing SingleParUpdate in MetricsInfo.h. Why are there two, and what is their relationship if any? If one wanted to cause confusion, this would be the way to go about it :-( - Martin
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Is it an OK? Have you tried it? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Alfredo Braunstein wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just return when vi.update_strategy == NoUpdate? And why are we calling paintText in the first place? The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Sorry if the questions don't make much sense, it's a long time I don't look at this part of the code... ;-) No surprise really because this part of the code has been rewritten since you left ;-) Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... No. :-) But I have not experienced this bug for a day after I applied the patch, so I guess the patch (and your analysis) is correct. Bo
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: > Alfredo Braunstein wrote: >> Abdelrazak Younes wrote: >> >>> Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? >>> Looks like a good analysis. >>> >>> I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. >>> I think you're right Stefan and the problem is most certainly caused by >>> a combination of mouse hover and SinglePar when the focus comes back. >> >> SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just >> return when vi.update_strategy == NoUpdate? And why are we calling >> paintText in the first place? > > The problem is that, when mouse hovering, no text painting should be > needed, only background. But, because of current architectur where text > is drawn _after_ background, we are forced to do the text painting. > Changing this (using text on transparent background painting) basically > needs a rewrite of rowpainter hence a 1.6 business). Ok. > Now, in case when mouse hovering hapens just after a SinglePar update > and at the same screen location, grey areas are drawn before and after > the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: >>> The problem is that, when mouse hovering, no text painting should be >>> needed, only background. But, because of current architectur where >>> text >>> is drawn _after_ background, we are forced to do the text painting. >>> Changing this (using text on transparent background painting) >>> basically >>> needs a rewrite of rowpainter hence a 1.6 business). >> >> Ok. >> >>> Now, in case when mouse hovering hapens just after a SinglePar update >>> and at the same screen location, grey areas are drawn before and >>> after >>> the current paragraph. I am not sure I am clear... >> >> Not completely, but thanks a lot anyway. >> So, why the NoUpdate flag if the background is to be repainted? And >> then, if >> NoUpdate still repaints the background, why do we have the grey >> areas bug, >> are vi.y1 and vi.y2 wrong for some reason? > > You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower > line of a paragraph, with update_strategy set the NoUpdate. With the > old behavior in this case the paragraph was redrawn correctly, but > then _all the remaining part_ of the screen was painted grey. Hence > the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Thanks, Alfredo
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: > Stefan Schimanski wrote: > > >>> The problem is that, when mouse hovering, no text painting should be > >>> needed, only background. But, because of current architectur where > >>> text > >>> is drawn _after_ background, we are forced to do the text painting. > >>> Changing this (using text on transparent background painting) > >>> basically > >>> needs a rewrite of rowpainter hence a 1.6 business). > >> > >> Ok. > >> > >>> Now, in case when mouse hovering hapens just after a SinglePar update > >>> and at the same screen location, grey areas are drawn before and > >>> after > >>> the current paragraph. I am not sure I am clear... > >> > >> Not completely, but thanks a lot anyway. > >> So, why the NoUpdate flag if the background is to be repainted? And > >> then, if > >> NoUpdate still repaints the background, why do we have the grey > >> areas bug, > >> are vi.y1 and vi.y2 wrong for some reason? > > > > You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower > > line of a paragraph, with update_strategy set the NoUpdate. With the > > old behavior in this case the paragraph was redrawn correctly, but > > then _all the remaining part_ of the screen was painted grey. Hence > > the grey bars in certain cases. > > Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just > using SingleParUpdate in this case. Actually the redraw of text is _always_ from vi.y1 to vi.y2. The SingleParUpdate is only meant to signal that there are still other paragraphs on the screen which _should not_ be greyed out. IIRC and nobody has overhauled this code since ;-/ - Martin
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 10:04:28PM +0300, Martin Vermeer wrote: > On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: > > Stefan Schimanski wrote: > > > > >>> The problem is that, when mouse hovering, no text painting should be > > >>> needed, only background. But, because of current architectur where > > >>> text > > >>> is drawn _after_ background, we are forced to do the text painting. > > >>> Changing this (using text on transparent background painting) > > >>> basically > > >>> needs a rewrite of rowpainter hence a 1.6 business). > > >> > > >> Ok. > > >> > > >>> Now, in case when mouse hovering hapens just after a SinglePar update > > >>> and at the same screen location, grey areas are drawn before and > > >>> after > > >>> the current paragraph. I am not sure I am clear... > > >> > > >> Not completely, but thanks a lot anyway. > > >> So, why the NoUpdate flag if the background is to be repainted? And > > >> then, if > > >> NoUpdate still repaints the background, why do we have the grey > > >> areas bug, > > >> are vi.y1 and vi.y2 wrong for some reason? > > > > > > You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower > > > line of a paragraph, with update_strategy set the NoUpdate. With the > > > old behavior in this case the paragraph was redrawn correctly, but > > > then _all the remaining part_ of the screen was painted grey. Hence > > > the grey bars in certain cases. > > > > Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just > > using SingleParUpdate in this case. > > Actually the redraw of text is _always_ from vi.y1 to vi.y2. The > SingleParUpdate is only meant to signal that there are still other paragraphs > on the screen which _should not_ be greyed out. IIRC and nobody has overhauled > this code since ;-/ Actually something seems to have happened... there is a bitstring func_attrib containing NoUpdate and SingleParUpdate as bits, in LyXAction.h; and then there is an enum ScreenUpdateStrategy also containing SingleParUpdate in MetricsInfo.h. Why are there two, and what is their relationship if any? If one wanted to cause confusion, this would be the way to go about it :-( - Martin
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Richard I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) //lyxerr par ascent: text.getPar(vi.p1).ascent() endl; -if (vi.y1 0 vi.update_strategy != SingleParUpdate) +if (vi.y1 0 vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below //lyxerr par descent: text.getPar(vi.p1).ascent() endl; -if (vi.y2 bv.workHeight() vi.update_strategy != SingleParUpdate) +if (vi.y2 bv.workHeight() vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Richard I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) //lyxerr << "par ascent: " << text.getPar(vi.p1).ascent() << endl; -if (vi.y1 > 0 && vi.update_strategy != SingleParUpdate) +if (vi.y1 > 0 && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below //lyxerr << "par descent: " << text.getPar(vi.p1).ascent() << endl; -if (vi.y2 < bv.workHeight() && vi.update_strategy != SingleParUpdate) +if (vi.y2 < bv.workHeight() && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
