Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: [snip] Perhaps you're referring to insettext/tabular specific code that decides which cells needs updating ? But that's not related to redrawings really, it's more a matter of rebreaking etc. (and it's broken in several circumstances) Yes John you are right and I see you're on the right trace just go on with your investigation. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Wed, Mar 19, 2003 at 05:07:35PM +0100, Juergen Vigna wrote: Yes John you are right and I see you're on the right trace just go on with your investigation. Well I've just hacked out all the direct update() calls, and things are breaking in a spectacular fashion :) john
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: [snip] Perhaps you're referring to insettext/tabular specific code that decides which cells needs updating ? But that's not related to redrawings really, it's more a matter of rebreaking etc. (and it's broken in several circumstances) Yes John you are right and I see you're on the right trace just go on with your investigation. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Wed, Mar 19, 2003 at 05:07:35PM +0100, Juergen Vigna wrote: > Yes John you are right and I see you're on the right trace just go > on with your investigation. Well I've just hacked out all the direct update() calls, and things are breaking in a spectacular fashion :) john
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This looks to be very silly indeed, so I guess I'm missing something. Why are we calling update(text) directly several times for one lfun ? Can we not just post the update, and then call it *once* at the end of handling the lfun (and at the end of handleKeypress and a couple of other spots I guess). It looks to me currently like we do an awful lot of unnecessary redrawing for no good reason ? I don't understand code like this : 400 bv-update(text, BufferView::SELECT | BufferView::FITCUR); 401 text-toggleFree(font, toggleall); 402 bv-update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) This code is related to selections and their redraw/drawing, it doesn't do that much actually have a better look at the update function and you'll see that actually most of this calls don't do that much. I explain you also why one update won't work because then we would have to do full redraw as Andre tell's us always. I think that full redraw was normal at the beginning, but it was (and IMO it still would be) way too slow when someone is typing fast! I didn't finish my explanation above ;), if we don't do a full redraw we have to clear the selection first then do the change, and after that redraw the selection as otherwise we would have drawing glitches and blue selection rectangles in spots where they should not be. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 09:23:54AM +0100, Juergen Vigna wrote:
I explain you also why one update won't work because then we would have
to do full redraw as Andre tell's us always. I think that full redraw
was normal at the beginning, but it was (and IMO it still would be) way
too slow when someone is typing fast!
No, it wouldn't.
Create a 20x20 table and type something.
Create a 20x20 tabular in math and type something.
Do you notice anything?
Andre'
PS: CutPastepress C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: CutPastepress C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try that but I don't know how to create the
tabular inside mathed.
As I said: Cutpaste that $...$ to the main lyx text, mark it, press C-m.
Is it a real InsetTabular?
No. It doesn't have multicols and fixed width columns and a few other bells
an whistles.
Well then I just don't have to test this, as if I would have an
InsetTabular with that restrictions I also could just do a full redraw
the problems are the other features (and I tried to do them doing a
full redraw, but it was *way* too slow, at least on the PC I had at
that time!)
Jug
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Administration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 / 564111 (direct 564172)
Fax: +39 0471 / 564122
mailto:[EMAIL PROTECTED]
http://www.wuerth-phoenix.com
**
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 12:27:51PM +0100, Juergen Vigna wrote: No. It doesn't have multicols and fixed width columns and a few other bells an whistles. Well then I just don't have to test this, as if I would have an InsetTabular with that restrictions I also could just do a full redraw the problems are the other features (and I tried to do them doing a full redraw, but it was *way* too slow, at least on the PC I had at that time!) This definitely won't change if fixed width is allowed. I just can't prove it right now as I haven't found the time so far to fix MathParInset to do proper alignment. I also fail to see how \multicol can influence the result significantly. Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 09:23:54AM +0100, Juergen Vigna wrote: 400 bv-update(text, BufferView::SELECT | BufferView::FITCUR); 401 text-toggleFree(font, toggleall); 402 bv-update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) This code is related to selections and their redraw/drawing, it doesn't do that much actually have a better look at the update function and you'll see that actually most of this calls don't do that much. Why are we removing a selection, drawing that, exposing it, making the change, drawing that and exposing it ? Given that the user has no input inbetween any of this sequence. I explain you also why one update won't work because then we would have to do full redraw as Andre tell's us always. I don't understand why. Can you explain further ? Either way, we only need to update from the refresh_y of where things changed (which will sometimes need to be a full draw, of course). I didn't finish my explanation above ;), if we don't do a full redraw we have to clear the selection first then do the change, and after that redraw the selection as otherwise we would have drawing glitches and blue selection rectangles in spots where they should not be. This just sounds like bugs to me, and several redraws (did you know each character press sends redraws twice even in a normal par ?) is not the correct solution. Do you mean cursor droppings ? regards john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 12:46:17PM +0100, Andre Poenitz wrote: Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. This is something of a silly thing to say. What you're saying is : Full redraw of an insettabular would be faster than partial redraw, if insettabular was rewritten. But insettabular has not been rewritten. And I do not see anybody stepping up to the plate for that either :) john
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. Well this is easy enough to try just forget about the inteligent redraw and set the update always to NEED_FULL_REDRAW and you'll see the difference. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This just sounds like bugs to me, and several redraws (did you know each character press sends redraws twice even in a normal par ?) is not the correct solution. Do you mean cursor droppings ? There are a lot of different situations when we have wrong redraws if we don't do the double draws. I know this because I tried to remove them some time ago and saw the results. There are various places where that happens, but I would now have to have a deeper look into the files to remember and as you say the whole update stuff is not what I call easy understandable. So if you think you have the ultimate solution just try it out ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:13:09PM +0100, Juergen Vigna wrote: Well this is easy enough to try just forget about the inteligent redraw and set the update always to NEED_FULL_REDRAW and you'll see the difference. Would that mean (almost) no effort is spent to be clever in this case? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:18:24PM +0100, Juergen Vigna wrote: There are a lot of different situations when we have wrong redraws if we don't do the double draws. I know this because I tried to remove them Then we should make the effort *now* to fix this properly, I think. I can understand this is likely to be no fun at all, but it's just not a maintainable solution to keep on covering up these errors. understandable. So if you think you have the ultimate solution just try it out ;) I will ! Let's see what breaks :) regards, john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 04:24:01PM +, John Levon wrote: So if you think you have the ultimate solution just try it out ;) I will ! Good boy. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Would that mean (almost) no effort is spent to be clever in this case? I don't understand your question here? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:31:11PM +0100, Juergen Vigna wrote: Andre Poenitz wrote: Would that mean (almost) no effort is spent to be clever in this case? I don't understand your question here? Currently we spend some effort to figure out which part of the screen needs a redraw. This computation costs time. I think removing all that clever code might yield a speed up because we would not spend the time for this computation. You say I could try it out by setting NEED_REDRAW(?sp). Ok, the effect of both is obviously a full redraw. The question is, whether setting NEED_REDRAW means that there is almost no time spend for the computation of what needs to be redrawn (because e.g. the code looks like if (!NEED_REDRAW) fancy_computation(); ), or whether this mean we would spend the same time for the guessing _plus_ the time for the full redraw. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:34:42PM +0100, Andre Poenitz wrote: Currently we spend some effort to figure out which part of the screen needs a redraw. This computation costs time. I am deeply dubious about this. Do you have some proof ? Working it out mostly consists of holding a y value, and setting refresh_y to it. Then there is some rather simple screen.C code. fancy_computation(); where is this code ? Given that opening an inset causes 4 actual redraws + exposes, I think looking at that would be a more obvious way to go ! john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 04:48:35PM +, John Levon wrote: fancy_computation(); where is this code ? I was asking whether such code exists. Given that opening an inset causes 4 actual redraws + exposes, I think looking at that would be a more obvious way to go ! Probably. But replacing it with a single one probably won't work together with the current cleverness. So the question is should we remove the cleverness first, face a slow down but retain LyX in a usable state and keep working from there by removing multiple redraws or should we remove multiple redraws first and fix problems afterwards. As current cvs is unusable for any real work anyway it does not matter much. _I_ would have taken the first approach, but if you work on it, it is obviously your choice. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:56:18PM +0100, Andre Poenitz wrote: I was asking whether such code exists. I do not believe it does. Probably. But replacing it with a single one probably won't work together with the current cleverness. I don't know what this cleverness is. Starting a redraw from a particular y is *not* clever. If there's somewhere that is a postRowPaint() that should be postPaint() under some circumstances, we can find those spots. But that's nothing to do with the repainting the *same* area lots of times. So the question is should we remove the cleverness first, face a slow down but retain LyX in a usable state and keep working from there by removing multiple redraws or should we remove multiple redraws first and fix problems afterwards. But I do not see any real cleverness, that is my point. The only previous cleverness we have was the background stuff, and I *did* remove that. Perhaps you're referring to insettext/tabular specific code that decides which cells needs updating ? But that's not related to redrawings really, it's more a matter of rebreaking etc. (and it's broken in several circumstances) john
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This looks to be very silly indeed, so I guess I'm missing something. Why are we calling update(text) directly several times for one "lfun" ? Can we not just post the update, and then call it *once* at the end of handling the lfun (and at the end of handleKeypress and a couple of other spots I guess). It looks to me currently like we do an awful lot of unnecessary redrawing for no good reason ? I don't understand code like this : 400 bv->update(text, BufferView::SELECT | BufferView::FITCUR); 401 text->toggleFree(font, toggleall); 402 bv->update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) This code is related to "selections" and their redraw/drawing, it doesn't do that much actually have a better look at the update function and you'll see that actually most of this calls don't do that much. I explain you also why one update won't work because then we would have to do "full redraw" as Andre tell's us always. I think that full redraw was normal at the beginning, but it was (and IMO it still would be) way too slow when someone is typing fast! I didn't finish my explanation above ;), if we don't do a "full redraw" we have to "clear the selection first" then do the change, and after that "redraw the selection" as otherwise we would have drawing glitches and blue selection rectangles in spots where they should not be. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 09:23:54AM +0100, Juergen Vigna wrote:
> I explain you also why one update won't work because then we would have
> to do "full redraw" as Andre tell's us always. I think that full redraw
> was normal at the beginning, but it was (and IMO it still would be) way
> too slow when someone is typing fast!
No, it wouldn't.
Create a 20x20 table and type something.
Create a 20x20 tabular in math and type something.
Do you notice anything?
Andre'
PS: Cut C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: Cut C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try that but I don't know how to create the
tabular inside mathed.
As I said: Cut that $...$ to the main lyx text, mark it, press C-m.
Is it a "real" InsetTabular?
No. It doesn't have multicols and fixed width columns and a few other bells
an whistles.
Well then I just don't have to test this, as if I would have an
InsetTabular with that restrictions I also could just do a "full redraw"
the problems are the "other" features (and I tried to do them doing a
"full redraw", but it was *way* too slow, at least on the PC I had at
that time!)
Jug
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Administration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 / 564111 (direct 564172)
Fax: +39 0471 / 564122
mailto:[EMAIL PROTECTED]
http://www.wuerth-phoenix.com
**
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 12:27:51PM +0100, Juergen Vigna wrote: > >No. It doesn't have multicols and fixed width columns and a few other bells > >an whistles. > > Well then I just don't have to test this, as if I would have an > InsetTabular with that restrictions I also could just do a "full redraw" > the problems are the "other" features (and I tried to do them doing a > "full redraw", but it was *way* too slow, at least on the PC I had at > that time!) This definitely won't change if fixed width is allowed. I just can't prove it right now as I haven't found the time so far to fix MathParInset to do proper alignment. I also fail to see how \multicol can influence the result significantly. Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 09:23:54AM +0100, Juergen Vigna wrote: > >400 bv->update(text, BufferView::SELECT | BufferView::FITCUR); > >401 text->toggleFree(font, toggleall); > >402 bv->update(text, BufferView::SELECT | BufferView::FITCUR | > >BufferView::CHANGE); > > > >Is this related to CHANGED_IN_DRAW ? (and if so, how ...) > > This code is related to "selections" and their redraw/drawing, it doesn't > do that much actually have a better look at the update function and you'll > see that actually most of this calls don't do that much. Why are we removing a selection, drawing that, exposing it, making the change, drawing that and exposing it ? Given that the user has no input inbetween any of this sequence. > I explain you also why one update won't work because then we would have > to do "full redraw" as Andre tell's us always. I don't understand why. Can you explain further ? Either way, we only need to update from the refresh_y of where things changed (which will sometimes need to be a full draw, of course). > I didn't finish my explanation above ;), if we don't do a "full redraw" > we have to "clear the selection first" then do the change, and after that > "redraw the selection" as otherwise we would have drawing glitches and blue > selection rectangles in spots where they should not be. This just sounds like bugs to me, and several redraws (did you know each character press sends redraws twice even in a normal par ?) is not the correct solution. Do you mean cursor droppings ? regards john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 12:46:17PM +0100, Andre Poenitz wrote: > Face it: Full redraw _is_ faster. This might have changed over time, > though, but it is the current state. This is something of a silly thing to say. What you're saying is : "Full redraw of an insettabular would be faster than partial redraw, if insettabular was rewritten". But insettabular has not been rewritten. And I do not see anybody stepping up to the plate for that either :) john
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. Well this is easy enough to try just forget about the "inteligent" redraw and set the update always to "NEED_FULL_REDRAW" and you'll see the difference. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This just sounds like bugs to me, and several redraws (did you know each character press sends redraws twice even in a normal par ?) is not the correct solution. Do you mean cursor droppings ? There are a lot of different situations when we have "wrong redraws" if we don't do the double draws. I know this because I tried to remove them some time ago and saw the results. There are various places where that happens, but I would now have to have a deeper look into the files to remember and as you say the whole update stuff is not what I call easy understandable. So if you think you have the ultimate solution just try it out ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:13:09PM +0100, Juergen Vigna wrote: > Well this is easy enough to try just forget about the "inteligent" > redraw and set the update always to "NEED_FULL_REDRAW" and you'll > see the difference. Would that mean (almost) no effort is spent to "be clever" in this case? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:18:24PM +0100, Juergen Vigna wrote: > There are a lot of different situations when we have "wrong redraws" if > we don't do the double draws. I know this because I tried to remove them Then we should make the effort *now* to fix this properly, I think. I can understand this is likely to be no fun at all, but it's just not a maintainable solution to keep on covering up these errors. > understandable. So if you think you have the ultimate solution just try > it out ;) I will ! Let's see what breaks :) regards, john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 04:24:01PM +, John Levon wrote: > > So if you think you have the ultimate solution just try it out ;) > > I will ! Good boy. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Would that mean (almost) no effort is spent to "be clever" in this case? I don't understand your question here? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:31:11PM +0100, Juergen Vigna wrote: > Andre Poenitz wrote: > >Would that mean (almost) no effort is spent to "be clever" in this case? > > I don't understand your question here? Currently we spend some effort to figure out which part of the screen needs a redraw. This computation costs time. I think removing all that clever code might yield a speed up because we would not spend the time for this computation. You say I could try it out by setting NEED_REDRAW(?sp). Ok, the effect of both is obviously a full redraw. The question is, whether setting NEED_REDRAW means that there is almost no time spend for the computation of what needs to be redrawn (because e.g. the code looks like if (!NEED_REDRAW) fancy_computation(); ), or whether this mean we would spend the same time for the guessing _plus_ the time for the full redraw. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:34:42PM +0100, Andre Poenitz wrote: > Currently we spend some effort to figure out which part of the screen needs > a redraw. This computation costs time. I am deeply dubious about this. Do you have some proof ? "Working it out" mostly consists of holding a y value, and setting refresh_y to it. Then there is some rather simple screen.C code. > fancy_computation(); where is this code ? Given that opening an inset causes 4 actual redraws + exposes, I think looking at that would be a more obvious way to go ! john
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 04:48:35PM +, John Levon wrote: > > fancy_computation(); > > where is this code ? I was asking whether such code exists. > Given that opening an inset causes 4 actual redraws + exposes, I think > looking at that would be a more obvious way to go ! Probably. But replacing it with a single one probably won't work together with the current cleverness. So the question is "should we remove the cleverness first, face a slow down but retain LyX in a usable state and keep working from there by removing multiple redraws" or "should we remove multiple redraws first and fix problems afterwards". As current cvs is unusable for any real work anyway it does not matter much. _I_ would have taken the first approach, but if you work on it, it is obviously your choice. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: BufferView_pimpl::update(blah) vs. update()
On Tue, Mar 18, 2003 at 05:56:18PM +0100, Andre Poenitz wrote: > I was asking whether such code exists. I do not believe it does. > Probably. But replacing it with a single one probably won't work together > with the current cleverness. I don't know what this "cleverness" is. Starting a redraw from a particular y is *not* clever. If there's somewhere that is a postRowPaint() that should be postPaint() under some circumstances, we can find those spots. But that's nothing to do with the repainting the *same* area lots of times. > So the question is "should we remove the cleverness first, face a slow down > but retain LyX in a usable state and keep working from there by removing > multiple redraws" or "should we remove multiple redraws first and fix > problems afterwards". But I do not see any real cleverness, that is my point. The only previous cleverness we have was the background stuff, and I *did* remove that. Perhaps you're referring to insettext/tabular specific code that decides which cells needs updating ? But that's not related to redrawings really, it's more a matter of rebreaking etc. (and it's broken in several circumstances) john
BufferView_pimpl::update(blah) vs. update()
This looks to be very silly indeed, so I guess I'm missing something. Why are we calling update(text) directly several times for one lfun ? Can we not just post the update, and then call it *once* at the end of handling the lfun (and at the end of handleKeypress and a couple of other spots I guess). It looks to me currently like we do an awful lot of unnecessary redrawing for no good reason ? I don't understand code like this : 400 bv-update(text, BufferView::SELECT | BufferView::FITCUR); 401 text-toggleFree(font, toggleall); 402 bv-update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) regards, john
BufferView_pimpl::update(blah) vs. update()
This looks to be very silly indeed, so I guess I'm missing something. Why are we calling update(text) directly several times for one "lfun" ? Can we not just post the update, and then call it *once* at the end of handling the lfun (and at the end of handleKeypress and a couple of other spots I guess). It looks to me currently like we do an awful lot of unnecessary redrawing for no good reason ? I don't understand code like this : 400 bv->update(text, BufferView::SELECT | BufferView::FITCUR); 401 text->toggleFree(font, toggleall); 402 bv->update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) regards, john
