Re: top_y() is killing us
Andre Poenitz wrote: So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? I think discussing helps thinking ;) The problem we have is that we do updating of the text in rows. so if the inset is embedded in a row and it changes it may be that we have to recalculate the whole row (therefore up and down). I don't see any easy solution for this as we cannot update first all insets and then the text, as we then don't know the exact x position of the inset and this gives us the width of the inset. I admit that I tried to come up with an example (and I know I knew of various), but now I come up with nothing. Why not let us create a branch and try out the solution to update all insets first (starting from the innermost childs!) and then update the text structure. After that doing the draw. And see what's happens. I won't do something like this in the main branch. And maybe it comes back to my mind what examples I had which did break this behaviour. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote: Andre Poenitz wrote: So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? I think discussing helps thinking ;) [Pretty unconventional approach nowadays. It seems that solving disputes by throwing a few bombs and killing a few people is becoming popular...] The problem we have is that we do updating of the text in rows. so if the inset is embedded in a row and it changes it may be that we have to recalculate the whole row (therefore up and down). Yes. We have nested containers in several levels. I don't see any easy solution for this as we cannot update first all insets and then the text, as we then don't know the exact x position of the inset and this gives us the width of the inset. Hah! The point is, the first phase fixes only the _size_, not the position. The position is not relevant for the computation of the size of the parent. At the end of the first phase everybody knows its size, but not its position. The actual positions are determined during the second phase. They would not even have to be stored if we had not to support mouse clicks or LFUN_SET_XY. Why not let us create a branch and try out the solution to update all insets first (starting from the innermost childs!) and then update the text structure. After that doing the draw. And see what's happens. I won't do something like this in the main branch. Well, I am still not too fond of branches... but ok. I won't be able to spend any time on it during the next three weeks, though (first some conference and than a few days off...) And maybe it comes back to my mind what examples I had which did break this behaviour. That would be indeed interesting. 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: top_y() is killing us
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote: I don't see any easy solution for this as we cannot update first all insets and then the text, as we then don't know the exact x position of the inset and this gives us the width of the inset. I still do not understand what the x position has to do with width. In fact, I've removed any such connection and cannot reproduce a problem ... Why not let us create a branch and try out the solution to update all insets first (starting from the innermost childs!) and then update the text structure. After that doing the draw. And see what's happens. I won't do something like this in the main branch. Sounds sensible regards john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 01:50:23PM +, John Levon wrote: I don't see any easy solution for this as we cannot update first all insets and then the text, as we then don't know the exact x position of the inset and this gives us the width of the inset. I still do not understand what the x position has to do with width. In fact, I've removed any such connection and cannot reproduce a problem ... I think this might have been the problem all the time: Understanding the differnce between 'size' and 'position'... 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: top_y() is killing us
On Fri, Mar 21, 2003 at 08:16:17AM +0100, Andre Poenitz wrote: Once the next redraw starts, the table column tells its child in the metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly and stores a width of 2 inches and whatever height it just determined. The table column can figure out its height from that. The enclosing float determines its size from the table. I suspect things could work if we have : void metrics(int max_width); if that's what you mean. We don't actually have a notion of an inset that fills up remaining space anyway. So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? Because getting this stuff working isn't quite as easy as you hope ? Dunno. john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 10:47:29AM +0100, Andre Poenitz wrote: Hah! The point is, the first phase fixes only the _size_, not the position. The position is not relevant for the computation of the size of the parent. Not true: think about a non-special-cased insetnewline. Its position directly affects the height of the cell. Now, currently, we don't have the concept of an hfill-ing inset, but if we're going to do this properly, the whole row breaking work has to become reworked as part of this metrics() stuff. And this means rewriting an awful lot of code. I won't be able to spend any time on it during the next three weeks, though (first some conference and than a few days off...) If you're willing to give things a go you can count on as much support + patches as I can muster :) regards john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 01:52:27PM +, John Levon wrote: metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly and stores a width of 2 inches and whatever height it just determined. The table column can figure out its height from that. The enclosing float determines its size from the table. I suspect things could work if we have : void metrics(int max_width); if that's what you mean. Yes. But as there are a few other things that need to be passed along, better use a struct for all parameters. This way the interface stays optically leaner, you can forward-declare the struct and adding a new parameter later is simple. Have a look at math_metricsinfo.[Ch]. This even contains a textwidth field already. You can actually move that thing to a more prominent position (i.e. src/metricsinfo), drop all the 'Math' prefixes and be done. Because getting this stuff working isn't quite as easy as you hope ? It's a bit more than a hope... 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: top_y() is killing us
On Fri, Mar 21, 2003 at 01:55:13PM +, John Levon wrote: If you're willing to give things a go you can count on as much support + patches as I can muster :) Ok. I have an hour or so left now. I'll create the metricsinfo stuff rigth now. 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: top_y() is killing us
On Fri, Mar 21, 2003 at 02:48:13PM +0100, Andre Poenitz wrote: Yes. But as there are a few other things that need to be passed along, better use a struct for all parameters. This way the interface stays optically leaner, you can forward-declare the struct and adding a new parameter later is simple. Or the temptation to hack in a solution by adding another parameter becomes too tempting... but yeah. regards john
Re: top_y() is killing us
Andre Poenitz wrote: So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? I think discussing helps thinking ;) The problem we have is that we do "updating" of the text in "rows". so if the "inset" is embedded in a row and it changes it may be that we have to recalculate the whole row (therefore up and down). I don't see any easy solution for this as we cannot "update" first all insets and then the text, as we then don't know the exact "x" position of the inset and this gives us the "width" of the inset. I admit that I tried to come up with an example (and I know I knew of various), but now I come up with nothing. Why not let us create a branch and try out the solution to update all insets first (starting from the innermost childs!) and then update the text structure. After that doing the draw. And see what's happens. I won't do something like this in the main branch. And maybe it comes back to my mind what examples I had which did break this behaviour. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote: > Andre Poenitz wrote: > >So why do we see several updates per redraw? > > > >Why does an inset communicate explicitly with its parent? > > I think discussing helps thinking ;) [Pretty unconventional approach nowadays. It seems that solving disputes by throwing a few bombs and killing a few people is becoming popular...] > The problem we have is that we do "updating" of the text in "rows". > so if the "inset" is embedded in a row and it changes it may be that > we have to recalculate the whole row (therefore up and down). Yes. We have nested containers in several levels. > I don't see any easy solution for this as we cannot "update" first > all insets and then the text, as we then don't know the exact "x" > position of the inset and this gives us the "width" of the inset. Hah! The point is, the first phase fixes only the _size_, not the position. The position is not relevant for the computation of the size of the parent. At the end of the first phase everybody knows its size, but not its position. The actual positions are determined during the second phase. They would not even have to be stored if we had not to support mouse clicks or LFUN_SET_XY. > Why not let us create a branch and try out the solution to update > all insets first (starting from the innermost childs!) and then update > the text structure. After that doing the draw. And see what's happens. > > I won't do something like this in the main branch. Well, I am still not too fond of branches... but ok. I won't be able to spend any time on it during the next three weeks, though (first some conference and than a few days off...) > And maybe it comes back to my mind what examples I had which did break > this behaviour. That would be indeed interesting. 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: top_y() is killing us
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote: > I don't see any easy solution for this as we cannot "update" first > all insets and then the text, as we then don't know the exact "x" > position of the inset and this gives us the "width" of the inset. I still do not understand what the x position has to do with width. In fact, I've removed any such connection and cannot reproduce a problem ... > Why not let us create a branch and try out the solution to update > all insets first (starting from the innermost childs!) and then update > the text structure. After that doing the draw. And see what's happens. > > I won't do something like this in the main branch. Sounds sensible regards john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 01:50:23PM +, John Levon wrote: > > I don't see any easy solution for this as we cannot "update" first > > all insets and then the text, as we then don't know the exact "x" > > position of the inset and this gives us the "width" of the inset. > > I still do not understand what the x position has to do with width. In > fact, I've removed any such connection and cannot reproduce a problem > ... I think this might have been the problem all the time: Understanding the differnce between 'size' and 'position'... 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: top_y() is killing us
On Fri, Mar 21, 2003 at 08:16:17AM +0100, Andre Poenitz wrote: > Once the next redraw starts, the table column tells its child in the > metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly > and stores a width of 2 inches and whatever height it just determined. The > table column can figure out its height from that. The enclosing float > determines its size from the table. I suspect things could work if we have : void metrics(int max_width); if that's what you mean. We don't actually have a notion of an inset that fills up "remaining space" anyway. > So why do we see several updates per redraw? > > Why does an inset communicate explicitly with its parent? Because getting this stuff working isn't quite as easy as you hope ? Dunno. john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 10:47:29AM +0100, Andre Poenitz wrote: > Hah! The point is, the first phase fixes only the _size_, not the position. > The position is not relevant for the computation of the size of the parent. Not true: think about a non-special-cased insetnewline. Its position directly affects the height of the cell. Now, currently, we don't have the concept of an hfill-ing inset, but if we're going to do this properly, the whole row breaking work has to become reworked as part of this metrics() stuff. And this means rewriting an awful lot of code. > I won't be able to spend any time on it during the next three weeks, though > (first some conference and than a few days off...) If you're willing to give things a go you can count on as much support + patches as I can muster :) regards john
Re: top_y() is killing us
On Fri, Mar 21, 2003 at 01:52:27PM +, John Levon wrote: > > metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly > > and stores a width of 2 inches and whatever height it just determined. The > > table column can figure out its height from that. The enclosing float > > determines its size from the table. > > I suspect things could work if we have : > > void metrics(int max_width); > > if that's what you mean. Yes. But as there are a few other things that need to be passed along, better use a struct for all parameters. This way the interface stays optically leaner, you can forward-declare the struct and adding a new parameter later is simple. Have a look at math_metricsinfo.[Ch]. This even contains a textwidth field already. You can actually move that thing to a more prominent position (i.e. src/metricsinfo), drop all the 'Math' prefixes and be done. > Because getting this stuff working isn't quite as easy as you hope ? It's a bit more than a hope... 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: top_y() is killing us
On Fri, Mar 21, 2003 at 01:55:13PM +, John Levon wrote: > If you're willing to give things a go you can count on as much support + > patches as I can muster :) Ok. I have an hour or so left now. I'll create the metricsinfo stuff rigth now. 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: top_y() is killing us
On Fri, Mar 21, 2003 at 02:48:13PM +0100, Andre Poenitz wrote: > Yes. But as there are a few other things that need to be passed along, > better use a struct for all parameters. This way the interface stays > optically leaner, you can forward-declare the struct and adding a new > parameter later is simple. Or the temptation to hack in a solution by adding another parameter becomes too tempting... but yeah. regards john
Re: top_y() is killing us
Andre Poenitz wrote: So what about the two-stage drawing? Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the LyXText inside the InsetText for? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:12:56PM +, John Levon wrote: Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... I'm not sure the actual drawing is slowest, it's not showing up big time in the profiles. Things like singleWidth() are. I am not suggesting otherwise. But by clearly separating metrics computation and actual drawing we make sure that things like singleWitdh() are called only once per redraw. I'm not really sure how I'd implement what you're suggesting anyway. We already have inset-width() ... Look at what mathed does: At a very high level (i.e InsetFormula::draw) the work is split. The first call to width() calls metrics() [ok, this is messy, but currently the easiest way to make sure that metrics() is called after loading of a buffer, too]. Afterwards, the real draw part is done, by calling the nested inset's draw() [which do not contain metrics computations anymore] We should move this separation to a higher level. I.e. whatever calls InsetFormula::draw() should first call InsetFormula::metrics() and the only the drawing part. At this point probably all insets need the separation of their individual draw() functions into metrics() and [real] draw(). And I seriously doubt I have enough understanding to do it. I have never worked out what the hell Inset::scroll() does, for example. Or the exact semantics of InsetCollapsable::need_update. Neither have I... 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: top_y() is killing us
Andre Poenitz wrote: Look at what mathed does: At a very high level (i.e InsetFormula::draw) the work is split. The first call to width() calls metrics() [ok, this is messy, but currently the easiest way to make sure that metrics() is called after loading of a buffer, too]. Afterwards, the real draw part is done, by calling the nested inset's draw() [which do not contain metrics computations anymore] I told you this already a lot of times, the redraw of mathed is really easy to do. You have all fixed width insets and the don't do a rebreak or resize themselfs to their environment. You cannot compare this to the complexity of InsetText you may compare this to a inset like lets say a InsetTabular if we wouldn't have the posibility of autobreaking rows (as it was in the first draft of the inset). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:36:38AM +0100, Juergen Vigna wrote: I told you this already a lot of times, the redraw of mathed is really easy to do. You have all fixed width insets and the don't do a rebreak or resize themselfs to their environment. You cannot compare this to the complexity of InsetText you may compare this to a inset like lets say a InsetTabular if we wouldn't have the posibility of autobreaking rows (as it was in the first draft of the inset). And I still do not believe that this makes a big difference. Btw, this is not exactly true: Whenever you change a macro definition, the size of the macro's expansions change, too. 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: top_y() is killing us
Andre Poenitz wrote: And I still do not believe that this makes a big difference. Well this is up to you Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote: But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the LyXText inside the InsetText for? If this was true, CHANGED_IN_DRAW would not exist. regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:17:12AM +0100, Andre Poenitz wrote: the drawing part. At this point probably all insets need the separation of their individual draw() functions into metrics() and [real] draw(). Net effect: the insettexts run through all the calculations entirely twice. Doesn't sound like a great idea ... regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 01:51:50PM +, John Levon wrote: the drawing part. At this point probably all insets need the separation of their individual draw() functions into metrics() and [real] draw(). Net effect: the insettexts run through all the calculations entirely twice. Doesn't sound like a great idea ... First of all, twice might be better than what we have now. Secondly, why should it do the calculation twice? The draw step consists only of put string 'foo' at position 'pos' 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: top_y() is killing us
On Thu, Mar 20, 2003 at 03:02:55PM +0100, Andre Poenitz wrote: First of all, twice might be better than what we have now. This is (incorrectly) assuming that just splitting the thing into two doesn't mean we don't need to do things multiple times still. It's all very well to talk about some hypothetical code base at some point in the future, but that is not what we have now, and not what I have will have to make working. Secondly, why should it do the calculation twice? The draw step consists only of put string 'foo' at position 'pos' And where do these positions come from ? Cached ? AIUI that's not what mathed does. So, you end up doing all the metrics again during the draw. Or you cache it and have some *very* fragile semantics of when a cache should be cleared or not. regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 02:23:17PM +, John Levon wrote:
This is (incorrectly) assuming that just splitting the thing into two
doesn't mean we don't need to do things multiple times still.
Not more than once per redraw.
Secondly, why should it do the calculation twice?
The draw step consists only of put string 'foo' at position 'pos'
And where do these positions come from ? Cached ?
Cached from the previous metrics() run.
AIUI that's not what mathed does. So, you end up doing all the metrics
again during the draw.
draw()
{
metrics();
real_draw();
}
Or you cache it and have some *very* fragile
semantics of when a cache should be cleared or not.
Maybe cache is the wrong word. It was originally intended as a cache but
as it turned out fast enough I decided not to try real caching and
instead re-calculate on each draw(). However, using it as a cache is
possible, and I had it running at some point of time, the problem was the
macro folding.
This is similar to line rebreaks in the outer world, so yes, real caching
might be difficult to achieve, but as one shot cache it just works fine.
Maybe I really should not call it 'cache'.
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: top_y() is killing us
On Thu, Mar 20, 2003 at 03:47:01PM +0100, Andre Poenitz wrote: This is (incorrectly) assuming that just splitting the thing into two doesn't mean we don't need to do things multiple times still. Not more than once per redraw. OK, what is your magical solution to the inset update problem. With details please ... This is similar to line rebreaks in the outer world, so yes, real caching might be difficult to achieve, but as one shot cache it just works fine. Maybe I really should not call it 'cache'. Well, I think I follow you a bit better now. In fact, that is what I am trying to do ! Basically make sure all inset updates have been done by the time we actually call draw. But it is beyond my ken (I cannot even get one small part of this to work, in fact). We could queue inset updates and do them all after an lfun etc, but I don't see how to get the sensible ordering of innermost-outermost. john
Re: top_y() is killing us
John Levon wrote: On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote: But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the LyXText inside the InsetText for? If this was true, CHANGED_IN_DRAW would not exist. I said most of the times, didn't I? This means we need to redo the calculations if at the time we get to the draw routine the drawing tells us we don't have all the space we thought we had. The problem is that we have this information for now only when the draw function is really called :( Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
John Levon wrote: Well, I think I follow you a bit better now. In fact, that is what I am trying to do ! Basically make sure all inset updates have been done by the time we actually call draw. But it is beyond my ken (I cannot even get one small part of this to work, in fact). As I told you in my earlier mail some informations you have only when you are in the real draw function, well actually we are interested for a test-rebreak only in the x position as if this changes it means we have to rebreak the whole text inside the inset. This is also the difference between an InsetText and a InsetMath as mathed does not care how large it will become and this assumption takes out the whole complexitiy! We could queue inset updates and do them all after an lfun etc, but I don't see how to get the sensible ordering of innermost-outermost. That's the problem! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 04:07:25PM +0100, Juergen Vigna wrote: I said most of the times, didn't I? Ooops, so you did ! This means we need to redo the calculations if at the time we get to the draw routine the drawing tells us we don't have all the space we thought we had. Are you aware how rare this actually is ? In my tests, I had trouble finding a situation where the width changed in draw() and we hadn't previously called update() with the new width already set... The problem is that we have this information for now only when the draw function is really called :( Can you describe an exact circumstance ? I'll add some printf's and a getMaxWidth() thingy in update() to see when it does actually happen. In the meantime, a solution to the FIXME in insetminipage.C would be greatly welcomed :) thanks, john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 02:59:04PM +, John Levon wrote:
Not more than once per redraw.
OK, what is your magical solution to the inset update problem. With
details please ...
Simple: There is no inset update problem as there won't be an inset update.
Handling an LFUN just changes the structure of the doc, the postion of the
cursor, whatever. It does not care about visual appearance at all.
If the handling is finished, we do a full redraw. [Later we might be a bit
more clever, but not now]. The full redraw consists of two phases. In
each phase the document tree is traversed in full and each phase carries
some information object containing objects like current font, current
textwidth etc.
The first phase is the metrics calculation. Each container (inset,
main text,...) adjusts the information object according to its needs (i.e.
a minipage would change the textwidth) and calls metrics() with this
information object on each of its children recursively. If this is
finished, the sizes of the children are known and the container itself can
compute its own size. Row breaking etc. would happen here. Afterwards it
saves this newly computed size in its local cache.
Example:
void MathFracInset::metrics(MathMetricsInfo mi) const
{
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(mi.base);
// determine size of two children (numerator and denominator)
cell(0).metrics(mi);
cell(1).metrics(mi);
// compute our own size
dim_.w = max(cell(0).width(), cell(1).width()) + 2;
dim_.a = cell(0).height() + 2 + 5;
dim_.d = cell(1).height() + 2 - 5;
}
In the second phase, we go down the tree again passing another information
object around, containing an actual painter object and a position. Again,
apply local changes. Using the precomputed sizes we are able to tell the
childeren where to start their drawing. Tell them to do so. Then do our own
drawing. Undo local changes to the information object. Return.
Example:
void MathFracInset::draw(MathPainterInfo pi, int x, int y) const
{
int m = x + width() / 2;
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(pi.base);
cell(0).draw(pi, m - cell(0).width() / 2, y - cell(0).descent() - 2 -
5);
cell(1).draw(pi, m - cell(1).width() / 2, y + cell(1).ascent() + 2 -
5);
if (!atop_)
pi.pain.line(x + 1, y - 5, x + width() - 2, y - 5,
LColor::math);
}
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: top_y() is killing us
On Thu, Mar 20, 2003 at 04:14:38PM +0100, Juergen Vigna wrote: As I told you in my earlier mail some informations you have only when you are in the real draw function, At the top most draw function, we would split drawing in two phases. So the first phase knows everything already. This is also the difference between an InsetText and a InsetMath as mathed does not care how large it will become and this assumption takes out the whole complexitiy! But it could take this into account easily. 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: top_y() is killing us
On Thu, Mar 20, 2003 at 05:50:05PM +0100, Andre Poenitz wrote: Handling an LFUN just changes the structure of the doc, the postion of the cursor, whatever. It does not care about visual appearance at all. If the handling is finished, we do a full redraw. [Later we might be a bit more clever, but not now]. The full redraw consists of two phases. In each phase the document tree is traversed in full and each phase carries some information object containing objects like current font, current textwidth etc. The first phase is the metrics calculation. Each container (inset, main text,...) adjusts the information object according to its needs (i.e. a minipage would change the textwidth) and calls metrics() with this information object on each of its children recursively. If this is finished, the sizes of the children are known and the container itself can compute its own size. Row breaking etc. would happen here. Afterwards it And how does it alter its *parent* when needed ? And its parent's parent ? This sounds tremendously like what already exists Andre, except you called update metrics instead, and you do a full redraw of the screen. It is doing this update/metrics traversal that is the complicated bit ! regards, john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote: And how does it alter its *parent* when needed ? Nothing knows about its parent except what it gets passed in the info structure. By returning something in the info structure. When the parent starts doing its calculations, the sizes of the children are fixed. This sounds tremendously like what already exists Andre, except you called update metrics instead, and you do a full redraw of the screen. It is doing this update/metrics traversal that is the complicated bit ! It is a simple depth first tree traversal... 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: top_y() is killing us
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote: And how does it alter its *parent* when needed ? And its parent's parent ? Ok, maybe I am realling missing the point: In what circumstances does an inset have to alter its parent [that can't be handled in the two-phase, parent-after-children approach]? Juergen bases all his statements on the same theory that such a thing is necessary, but I really can't see an example. 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: top_y() is killing us
On Thu, Mar 20, 2003 at 06:08:44PM +0100, Andre Poenitz wrote: And how does it alter its *parent* when needed ? And its parent's parent ? Ok, maybe I am realling missing the point: In what circumstances does an inset have to alter its parent [that can't be handled in the two-phase, parent-after-children approach]? minipage is 45% of column width. Minipage is inside a table column that we have just altered to have a fixed width of 2 inches. The width of this column dictates the minipage width which dictates the breaking of the cell which dictates the height of the minipage's row which dictates the height of the table which dictates the height of the float which contains the table which dictates the height of the outermost row. Things like that... Simpler example: inlined ERT. Its contents (changed when you type a character) need to size to the contents. Now you're about to say : well the parent should enquire its child for its size in the first phase ? That is essentially what is happening now ! regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 05:38:44PM +, John Levon wrote: minipage is 45% of column width. Minipage is inside a table column that we have just altered to have a fixed width of 2 inches. The width of this column dictates the minipage width which dictates the breaking of the cell which dictates the height of the minipage's row which dictates the height of the table which dictates the height of the float which contains the table which dictates the height of the outermost row. So we'd just change the width. Once the next redraw starts, the table column tells its child in the metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly and stores a width of 2 inches and whatever height it just determined. The table column can figure out its height from that. The enclosing float determines its size from the table. There is no need whatsoever for the minipage to know that it is enclosed by something, it will be told in due time about restrictions in the environment it lives it (i.e. by saying textwidth=2 inches in the metrics phase) Simpler example: inlined ERT. Its contents (changed when you type a character) need to size to the contents. Now you're about to say : well the parent should enquire its child for its size in the first phase ? That is essentially what is happening now ! So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? 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: top_y() is killing us
Andre Poenitz wrote: So what about the two-stage drawing? Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the "LyXText" inside the InsetText for? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:12:56PM +, John Levon wrote: > > Give the insets a small cache of width/ascent/descent (you could steal from > > math_diminset I suppose), fill the cache of an inset in the first stage > > according to the size of the contents of the inset, and do all the drawing > > in the second stage... > > I'm not sure the actual drawing is slowest, it's not showing up big time > in the profiles. Things like singleWidth() are. I am not suggesting otherwise. But by clearly separating metrics computation and actual drawing we make sure that "things like singleWitdh()" are called only once per redraw. > I'm not really sure how I'd implement what you're suggesting anyway. We > already have inset->width() ... Look at what mathed does: At a very high level (i.e InsetFormula::draw) the work is split. The first call to width() calls metrics() [ok, this is messy, but currently the easiest way to make sure that metrics() is called after loading of a buffer, too]. Afterwards, the real draw part is done, by calling the nested inset's draw() [which do not contain metrics computations anymore] We should move this separation to a higher level. I.e. whatever calls InsetFormula::draw() should first call InsetFormula::metrics() and the only the drawing part. At this point probably all insets need the separation of their individual draw() functions into metrics() and [real] draw(). > And I seriously doubt I have enough understanding to do it. I have never > worked out what the hell Inset::scroll() does, for example. > Or the exact semantics of InsetCollapsable::need_update. Neither have I... 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: top_y() is killing us
Andre Poenitz wrote: Look at what mathed does: At a very high level (i.e InsetFormula::draw) the work is split. The first call to width() calls metrics() [ok, this is messy, but currently the easiest way to make sure that metrics() is called after loading of a buffer, too]. Afterwards, the real draw part is done, by calling the nested inset's draw() [which do not contain metrics computations anymore] I told you this already a lot of times, the redraw of mathed is "really" easy to do. You have all fixed width insets and the don't do a rebreak or resize themselfs to their environment. You cannot compare this to the complexity of InsetText you may compare this to a inset like lets say a InsetTabular if we wouldn't have the posibility of autobreaking rows (as it was in the first draft of the inset). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:36:38AM +0100, Juergen Vigna wrote: > I told you this already a lot of times, the redraw of mathed is "really" > easy to do. You have all fixed width insets and the don't do a rebreak or > resize themselfs to their environment. You cannot compare this to the > complexity of InsetText you may compare this to a inset like lets say > a InsetTabular if we wouldn't have the posibility of autobreaking rows > (as it was in the first draft of the inset). And I still do not believe that this makes a big difference. Btw, this is not exactly true: Whenever you change a macro definition, the size of the macro's expansions change, too. 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: top_y() is killing us
Andre Poenitz wrote: And I still do not believe that this makes a big difference. Well this is up to you Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote: > But we do this already we calculate all the matrices for drawing and > in the draw function we (most of the time) do just drawing and that > is pretty fast!) or what do you think do we use the "LyXText" inside > the InsetText for? If this was true, CHANGED_IN_DRAW would not exist. regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 09:17:12AM +0100, Andre Poenitz wrote: > the drawing part. At this point probably all insets need the separation of > their individual draw() functions into metrics() and [real] draw(). Net effect: the insettexts run through all the calculations entirely twice. Doesn't sound like a great idea ... regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 01:51:50PM +, John Levon wrote: > > the drawing part. At this point probably all insets need the separation of > > their individual draw() functions into metrics() and [real] draw(). > > Net effect: the insettexts run through all the calculations entirely > twice. Doesn't sound like a great idea ... First of all, "twice" might be better than what we have now. Secondly, why should it do the calculation twice? The draw step consists only of "put string 'foo' at position 'pos'" 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: top_y() is killing us
On Thu, Mar 20, 2003 at 03:02:55PM +0100, Andre Poenitz wrote: > First of all, "twice" might be better than what we have now. This is (incorrectly) assuming that just splitting the thing into two doesn't mean we don't need to do things multiple times still. It's all very well to talk about some hypothetical code base at some point in the future, but that is not what we have now, and not what I have will have to make working. > Secondly, why should it do the calculation twice? > The draw step consists only of "put string 'foo' at position 'pos'" And where do these positions come from ? Cached ? AIUI that's not what mathed does. So, you end up doing all the metrics again during the draw. Or you cache it and have some *very* fragile semantics of when a cache should be cleared or not. regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 02:23:17PM +, John Levon wrote:
> This is (incorrectly) assuming that just splitting the thing into two
> doesn't mean we don't need to do things multiple times still.
Not more than once per redraw.
> > Secondly, why should it do the calculation twice?
> > The draw step consists only of "put string 'foo' at position 'pos'"
>
> And where do these positions come from ? Cached ?
Cached from the previous metrics() run.
> AIUI that's not what mathed does. So, you end up doing all the metrics
> again during the draw.
draw()
{
metrics();
real_draw();
}
> Or you cache it and have some *very* fragile
> semantics of when a cache should be cleared or not.
Maybe "cache" is the wrong word. It was originally intended as a cache but
as it turned out fast enough I decided not to try "real caching" and
instead re-calculate on each draw(). However, using it as a cache is
possible, and I had it running at some point of time, the problem was the
"macro folding".
This is similar to line rebreaks in the outer world, so yes, real caching
might be difficult to achieve, but as "one shot cache" it just works fine.
Maybe I really should not call it 'cache'.
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: top_y() is killing us
On Thu, Mar 20, 2003 at 03:47:01PM +0100, Andre Poenitz wrote: > > This is (incorrectly) assuming that just splitting the thing into two > > doesn't mean we don't need to do things multiple times still. > > Not more than once per redraw. OK, what is your magical solution to the inset update problem. With details please ... > This is similar to line rebreaks in the outer world, so yes, real caching > might be difficult to achieve, but as "one shot cache" it just works fine. > > Maybe I really should not call it 'cache'. Well, I think I follow you a bit better now. In fact, that is what I am trying to do ! Basically make sure all inset updates have been done by the time we actually call draw. But it is beyond my ken (I cannot even get one small part of this to work, in fact). We could queue inset updates and do them all after an lfun etc, but I don't see how to get the sensible ordering of innermost->outermost. john
Re: top_y() is killing us
John Levon wrote: On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote: But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the "LyXText" inside the InsetText for? If this was true, CHANGED_IN_DRAW would not exist. I said "most of the times", didn't I? This means we need to redo the calculations if at the time we get to the draw routine the drawing tells us we don't have all the space we thought we had. The problem is that we have this information for now only when the draw function is really called :( Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
John Levon wrote: Well, I think I follow you a bit better now. In fact, that is what I am trying to do ! Basically make sure all inset updates have been done by the time we actually call draw. But it is beyond my ken (I cannot even get one small part of this to work, in fact). As I told you in my earlier mail some informations you have only when you are in the real draw function, well actually we are interested for a "test-rebreak" only in the "x" position as if this changes it means we have to rebreak the whole text inside the inset. This is also the difference between an InsetText and a InsetMath as mathed does not care how large it will become and this assumption takes out the whole complexitiy! We could queue inset updates and do them all after an lfun etc, but I don't see how to get the sensible ordering of innermost->outermost. That's the problem! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 04:07:25PM +0100, Juergen Vigna wrote: > I said "most of the times", didn't I? Ooops, so you did ! > This means we need to redo > the calculations if at the time we get to the draw routine the > drawing tells us we don't have all the space we thought we had. Are you aware how rare this actually is ? In my tests, I had trouble finding a situation where the width changed in draw() and we hadn't previously called update() with the new width already set... > The problem is that we have this information for now only when the > draw function is really called :( Can you describe an exact circumstance ? I'll add some printf's and a getMaxWidth() thingy in update() to see when it does actually happen. In the meantime, a solution to the FIXME in insetminipage.C would be greatly welcomed :) thanks, john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 02:59:04PM +, John Levon wrote:
> > Not more than once per redraw.
>
> OK, what is your magical solution to the inset update problem. With
> details please ...
Simple: There is no inset update problem as there won't be an inset update.
Handling an LFUN just changes the structure of the doc, the postion of the
cursor, whatever. It does not care about visual appearance at all.
If the handling is finished, we do a full redraw. [Later we might be a bit
more clever, but not now]. The full redraw consists of two phases. In
each phase the document tree is traversed in full and each phase carries
some "information object" containing objects like current font, current
textwidth etc.
The first phase is the "metrics calculation". Each container (inset,
main text,...) adjusts the information object according to its needs (i.e.
a minipage would change the textwidth) and calls metrics() with this
information object on each of its children recursively. If this is
finished, the sizes of the children are known and the container itself can
compute its own size. Row breaking etc. would happen here. Afterwards it
saves this newly computed size in its local "cache".
Example:
void MathFracInset::metrics(MathMetricsInfo & mi) const
{
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(mi.base);
// determine size of two children (numerator and denominator)
cell(0).metrics(mi);
cell(1).metrics(mi);
// compute our own size
dim_.w = max(cell(0).width(), cell(1).width()) + 2;
dim_.a = cell(0).height() + 2 + 5;
dim_.d = cell(1).height() + 2 - 5;
}
In the second phase, we go down the tree again passing another "information
object" around, containing an actual painter object and a position. Again,
apply local changes. Using the precomputed sizes we are able to tell the
childeren where to start their drawing. Tell them to do so. Then do our own
drawing. Undo local changes to the information object. Return.
Example:
void MathFracInset::draw(MathPainterInfo & pi, int x, int y) const
{
int m = x + width() / 2;
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(pi.base);
cell(0).draw(pi, m - cell(0).width() / 2, y - cell(0).descent() - 2 -
5);
cell(1).draw(pi, m - cell(1).width() / 2, y + cell(1).ascent() + 2 -
5);
if (!atop_)
pi.pain.line(x + 1, y - 5, x + width() - 2, y - 5,
LColor::math);
}
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: top_y() is killing us
On Thu, Mar 20, 2003 at 04:14:38PM +0100, Juergen Vigna wrote: > As I told you in my earlier mail some informations you have only when > you are in the real draw function, At the top most draw function, we would split drawing in two phases. So the first phase knows "everything" already. > This is also the difference between an InsetText and a InsetMath as > mathed does not care how large it will become and this assumption takes > out the whole complexitiy! But it could take this into account easily. 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: top_y() is killing us
On Thu, Mar 20, 2003 at 05:50:05PM +0100, Andre Poenitz wrote: > Handling an LFUN just changes the structure of the doc, the postion of the > cursor, whatever. It does not care about visual appearance at all. > > If the handling is finished, we do a full redraw. [Later we might be a bit > more clever, but not now]. The full redraw consists of two phases. In > each phase the document tree is traversed in full and each phase carries > some "information object" containing objects like current font, current > textwidth etc. > > The first phase is the "metrics calculation". Each container (inset, > main text,...) adjusts the information object according to its needs (i.e. > a minipage would change the textwidth) and calls metrics() with this > information object on each of its children recursively. If this is > finished, the sizes of the children are known and the container itself can > compute its own size. Row breaking etc. would happen here. Afterwards it And how does it alter its *parent* when needed ? And its parent's parent ? This sounds tremendously like what already exists Andre, except you called "update" "metrics" instead, and you do a full redraw of the screen. It is doing this update/metrics traversal that is the complicated bit ! regards, john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote: > And how does it alter its *parent* when needed ? Nothing knows about its parent except what it gets passed in the info structure. By returning something in the info structure. When the parent starts doing its calculations, the sizes of the children are fixed. > This sounds tremendously like what already exists Andre, except you > called "update" "metrics" instead, and you do a full redraw of the > screen. It is doing this update/metrics traversal that is the > complicated bit ! It is a simple depth first tree traversal... 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: top_y() is killing us
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote: > And how does it alter its *parent* when needed ? And its parent's parent ? Ok, maybe I am realling missing the point: In what circumstances does an inset have to alter its parent [that can't be handled in the two-phase, parent-after-children approach]? Juergen bases all his statements on the same theory that such a thing is necessary, but I really can't see an example. 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: top_y() is killing us
On Thu, Mar 20, 2003 at 06:08:44PM +0100, Andre Poenitz wrote: > > And how does it alter its *parent* when needed ? And its parent's parent ? > > Ok, maybe I am realling missing the point: > > In what circumstances does an inset have to alter its parent [that can't be > handled in the two-phase, parent-after-children approach]? minipage is 45% of column width. Minipage is inside a table column that we have just altered to have a fixed width of 2 inches. The width of this column dictates the minipage width which dictates the breaking of the cell which dictates the height of the minipage's row which dictates the height of the table which dictates the height of the float which contains the table which dictates the height of the outermost row. Things like that... Simpler example: inlined ERT. Its contents (changed when you type a character) need to size to the contents. Now you're about to say : "well the parent should enquire its child for its size in the first phase" ? That is essentially what is happening now ! regards john
Re: top_y() is killing us
On Thu, Mar 20, 2003 at 05:38:44PM +, John Levon wrote: > minipage is 45% of column width. Minipage is inside a table column that > we have just altered to have a fixed width of 2 inches. The width of > this column dictates the minipage width which dictates the breaking of > the cell which dictates the height of the minipage's row which dictates > the height of the table which dictates the height of the float which > contains the table which dictates the height of the outermost row. So we'd just change the width. Once the next redraw starts, the table column tells its child in the metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly and stores a width of 2 inches and whatever height it just determined. The table column can figure out its height from that. The enclosing float determines its size from the table. There is no need whatsoever for the minipage to know that it is enclosed by something, it will be told in due time about restrictions in the environment it lives it (i.e. by saying textwidth=2 inches in the metrics phase) > Simpler example: inlined ERT. Its contents (changed when you type a > character) need to size to the contents. Now you're about to say : "well > the parent should enquire its child for its size in the first phase" ? > That is essentially what is happening now ! So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? 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: top_y() is killing us
John == John Levon [EMAIL PROTECTED] writes: John The iteration through all the rows ... John Why doesn't a row know its position ? Because we would have to update all the positions when inserting a new row? When is top_y() called? JMarc
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 02:58:37PM +0100, Jean-Marc Lasgouttes wrote: Because we would have to update all the positions when inserting a new row? That's a lot less common than getRowNearY(), top_y(), etc. When is top_y() called? Every cursor movement, click, motion ... this is new stuff though john
Re: top_y() is killing us
John == John Levon [EMAIL PROTECTED] writes: When is top_y() called? John Every cursor movement, click, motion ... John this is new stuff though So presumably some of the clever but annoying stuff we had was useful? ;) JMarc
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:09:03PM +0100, Jean-Marc Lasgouttes wrote: So presumably some of the clever but annoying stuff we had was useful? ;) No, this is entirely related to Alfredo's work, which is orthogonal to the stuff I've been ripping out. regards john
Re: top_y() is killing us
John Levon wrote: The iteration through all the rows ... Are you sure it's significative? We can always try the 'old way' with a four line change like I did before. I've never detected a slowdown. Why doesn't a row know its position ? I'll bet that this will be easy to do. When does row positions can be updated? On rowpaint and row insert/delete I presume? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote: Are you sure it's significative? We can always try the 'old way' with a four line change like I did before. I've never detected a slowdown. It towers over everything else in the profiles. I'll bet that this will be easy to do. When does row positions can be updated? On rowpaint and row insert/delete I presume? Suppose so yep ... john
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote: I'll bet that this will be easy to do. When does row positions can be updated? On rowpaint and row insert/delete I presume? Actually, also whenever a row-height() can change, e.g. set font john
Re: top_y() is killing us
John Levon wrote: Actually, also whenever a row-height() can change, e.g. set font on LyXText::setHeightOfRow() would suffice? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:49:10PM +0100, Alfredo Braunstein wrote: Actually, also whenever a row-height() can change, e.g. set font on LyXText::setHeightOfRow() would suffice? plus removeRow, I guess ... dunno. john
Re: top_y() is killing us
John Levon wrote: on LyXText::setHeightOfRow() would suffice? plus removeRow, I guess ... dunno. I'll make a try. Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:52:52PM +0100, Alfredo Braunstein wrote: I'll make a try. Alfredo Great ! john
Re: top_y() is killing us
I don't really read all of the mails arriving right now (there is just too much traffic), but I overscan all of them fast. Now I'm a bit worried about the actual state of the lyx developement are you all sure we will not end up as in the old development tree? I hope you try to hold on yourself and don't start changing stuff in too many places otherwise we will never be able to see what changes broke behaviour and we will therefore not be able to fix all of the newly introduced bugs. A bit worried, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:14:49PM +0100, Juergen Vigna wrote: I don't really read all of the mails arriving right now (there is just too much traffic), but I overscan all of them fast. Now I'm a bit worried about the actual state of the lyx developement are you all sure we will not end up as in the old development tree? We currently have : o the assert (bugs always there) o a new DEPM crash o some new drawing problems o slowdown of top_y() o anchor row setting on doc shorter than the workarea is not ideal That's as much as I'm really aware of. broke behaviour and we will therefore not be able to fix all of the newly introduced bugs. At the worst, we can do -D 1 week ago -D now and go back. But I really don't think it will be necessary. regards, john
Re: top_y() is killing us
John Levon wrote: o slowdown of top_y() o anchor row setting on doc shorter than the workarea is not ideal These two are my bad but are pretty isolated and can be 'eliminated' by adding four lines to the existing code Btw, what's the problem with the second? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:20:41PM +0100, Alfredo Braunstein wrote: Btw, what's the problem with the second? Create a new document, type a few rows/pars of text, add afootnote, then close the footnote. The top row becomes the row containing the footnote, but it should be firstrow. regards john
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 04:22:57PM +, John Levon wrote: We currently have : o the assert (bugs always there) o a new DEPM crash o some new drawing problems o slowdown of top_y() o anchor row setting on doc shorter than the workarea is not ideal That's as much as I'm really aware of. My bibkey breaking... 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: top_y() is killing us
On Wed, Mar 19, 2003 at 05:23:17PM +0100, Andre Poenitz wrote: That's as much as I'm really aware of. My bibkey breaking... Oh yeah. and use_amsmath :)) john
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:23:17PM +0100, Andre Poenitz wrote:
My bibkey breaking...
I'm going to stop now, btw. I hacked out the direct updates (below)
and it breaks everything so badly that there is no point attempting
(ever) cleaning this up.
john
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.347
diff -u -p -r1.347 BufferView_pimpl.C
--- BufferView_pimpl.C 19 Mar 2003 14:45:04 - 1.347
+++ BufferView_pimpl.C 19 Mar 2003 16:30:11 -
@@ -499,9 +499,64 @@ void BufferView::Pimpl::workAreaResize()
}
+void BufferView::Pimpl::updateInset(Inset * inset)
+{
+ if (!inset || !available()) {
+ lyxerr calling updateInset(), no inset endl;
+ return;
+ }
+
+ lyxerr calling updateInset() endl;
+
+ // first check for locking insets
+ if (bv_-theLockingInset()) {
+ if (bv_-theLockingInset() == inset) {
+ if (bv_-text-updateInset(inset)) {
+ lyxerr Calling update() within endl;
+ //update();
+ updateScrollbar();
+ return;
+ }
+ } else if (bv_-theLockingInset()-updateInsetInInset(bv_, inset)) {
+ if (bv_-text-updateInset(bv_-theLockingInset())) {
+ lyxerr Calling update() within 2 endl;
+ //update();
+ updateScrollbar();
+ return;
+ }
+ }
+ }
+
+ // then check if the inset is a top_level inset (has no owner)
+ // if yes do the update as always otherwise we have to update the
+ // toplevel inset where this inset is inside
+ Inset * tl_inset = inset;
+ while (tl_inset-owner())
+ tl_inset = tl_inset-owner();
+ hideCursor();
+ if (tl_inset == inset) {
+ update(BufferView::UPDATE);
+ if (bv_-text-updateInset(inset)) {
+ update(BufferView::SELECT);
+ return;
+ }
+ } else if (static_castUpdatableInset *(tl_inset)
+ -updateInsetInInset(bv_, inset))
+ {
+ if (bv_-text-updateInset(tl_inset)) {
+ lyxerr Calling update() within 3 endl;
+ // update();
+ updateScrollbar();
+ }
+ }
+}
+
+
void BufferView::Pimpl::update()
{
+ lyxerr calling update() endl;
if (!bv_-theLockingInset() || !bv_-theLockingInset()-nodraw()) {
+ lyxerr actually doing update() endl;
screen().update(*bv_);
bool fitc = false;
while (bv_-text-status() == LyXText::CHANGED_IN_DRAW) {
@@ -539,12 +594,14 @@ void BufferView::Pimpl::update(LyXText *
text-fullRebreak();
+#if 0
if (text-inset_owner) {
text-inset_owner-setUpdateStatus(bv_, InsetText::NONE);
updateInset(text-inset_owner);
} else {
update();
}
+#endif
}
@@ -558,12 +615,14 @@ void BufferView::Pimpl::update(BufferVie
text-fullRebreak();
+#if 0
if (text-inset_owner) {
text-inset_owner-setUpdateStatus(bv_, InsetText::NONE);
updateInset(text-inset_owner);
} else {
update();
}
+#endif
}
@@ -942,6 +1001,7 @@ bool BufferView::Pimpl::dispatch(FuncReq
// Make sure that the cached BufferView is correct.
FuncRequest ev = ev_in;
ev.setView(bv_);
+ bool ret = true;
lyxerr[Debug::ACTION] BufferView::Pimpl::Dispatch:
action[ ev.action ']'
@@ -1270,10 +1330,10 @@ bool BufferView::Pimpl::dispatch(FuncReq
break;
default:
- return bv_-getLyXText()-dispatch(FuncRequest(ev, bv_));
+ ret = bv_-getLyXText()-dispatch(FuncRequest(ev, bv_));
} // end of switch
- return true;
+ return ret;
}
@@ -1335,50 +1395,4 @@ bool BufferView::Pimpl::insertInset(Inse
unFreezeUndo();
return true;
-}
-
-
-void BufferView::Pimpl::updateInset(Inset * inset)
-{
- if (!inset || !available())
- return;
-
- // first check for locking insets
- if (bv_-theLockingInset()) {
- if (bv_-theLockingInset() == inset) {
- if (bv_-text-updateInset(inset)) {
- update();
- updateScrollbar();
- return;
- }
- } else if (bv_-theLockingInset()-updateInsetInInset(bv_, inset)) {
- if
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 04:37:39PM +, John Levon wrote: I'm going to stop now, btw. I hacked out the direct updates (below) and it breaks everything so badly that there is no point attempting (ever) cleaning this up. So what about the two-stage drawing? Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... 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: top_y() is killing us
On Wed, Mar 19, 2003 at 05:34:54PM +0100, Andre Poenitz wrote: So what about the two-stage drawing? Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... I'm not sure the actual drawing is slowest, it's not showing up big time in the profiles. Things like singleWidth() are. I'm not really sure how I'd implement what you're suggesting anyway. We already have inset-width() ... And I seriously doubt I have enough understanding to do it. I have never worked out what the hell Inset::scroll() does, for example. Or the exact semantics of InsetCollapsable::need_update. john
Re: top_y() is killing us
John Levon wrote: Create a new document, type a few rows/pars of text, add afootnote, then close the footnote. The top row becomes the row containing the footnote, but it should be firstrow. I cannot reproduce this. Can you be more explicit? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 10:26:20PM +0100, Alfredo Braunstein wrote: I cannot reproduce this. Can you be more explicit? Load the attached, cut the footnote, paste the footnote (with control-v) at the end of the document. We scroll to a position that doesn't seem natural to me (and also, it doesn't help that our scrollbar callculation is as wrong as it usually is :( john
Re: top_y() is killing us
John Levon wrote: Load the attached, cut the footnote, paste the footnote (with control-v) Be serious and attach something then. ;) Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 10:34:39PM +0100, Alfredo Braunstein wrote: Be serious and attach something then. ;) oops john #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 223 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes 0 \end_header \layout Standard dogkey \begin_inset Foot collapsed true \layout Standard \end_inset \layout Standard dsa \layout Standard dsa \layout Standard dsa \layout Standard dsa \layout Standard dsasdsad \layout Standard sadsa \layout Standard dsa \the_end
Re: top_y() is killing us
John Levon [EMAIL PROTECTED] writes: | On Wed, Mar 19, 2003 at 10:26:20PM +0100, Alfredo Braunstein wrote: | | I cannot reproduce this. Can you be more explicit? | | Load the attached, cut the footnote, paste the footnote (with control-v) | at the end of the document. Is paste working? Hmm... -- Lgb
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 11:54:19PM +0100, Lars Gullik Bj?nnes wrote: | Load the attached, cut the footnote, paste the footnote (with control-v) | at the end of the document. Is paste working? In this circumstance, at least. john
Re: top_y() is killing us
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> The iteration through all the rows ... John> Why doesn't a row know its position ? Because we would have to update all the positions when inserting a new row? When is top_y() called? JMarc
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 02:58:37PM +0100, Jean-Marc Lasgouttes wrote: > Because we would have to update all the positions when inserting a new > row? That's a lot less common than getRowNearY(), top_y(), etc. > When is top_y() called? Every cursor movement, click, motion ... this is new stuff though john
Re: top_y() is killing us
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> When is top_y() called? John> Every cursor movement, click, motion ... John> this is new stuff though So presumably some of the "clever but annoying" stuff we had was useful? ;) JMarc
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:09:03PM +0100, Jean-Marc Lasgouttes wrote: > So presumably some of the "clever but annoying" stuff we had was > useful? ;) No, this is entirely related to Alfredo's work, which is orthogonal to the stuff I've been ripping out. regards john
Re: top_y() is killing us
John Levon wrote: > The iteration through all the rows ... Are you sure it's significative? We can always try the 'old way' with a four line change like I did before. I've never detected a slowdown. > Why doesn't a row know its position ? I'll bet that this will be easy to do. When does row positions can be updated? On rowpaint and row insert/delete I presume? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote: > Are you sure it's significative? We can always try the 'old way' with a four > line change like I did before. I've never detected a slowdown. It towers over everything else in the profiles. > I'll bet that this will be easy to do. When does row positions can be > updated? On rowpaint and row insert/delete I presume? Suppose so yep ... john
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote: > I'll bet that this will be easy to do. When does row positions can be > updated? On rowpaint and row insert/delete I presume? Actually, also whenever a row->height() can change, e.g. set font john
Re: top_y() is killing us
John Levon wrote: > Actually, also whenever a row->height() can change, e.g. set font on LyXText::setHeightOfRow() would suffice? Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:49:10PM +0100, Alfredo Braunstein wrote: > > Actually, also whenever a row->height() can change, e.g. set font > > on LyXText::setHeightOfRow() would suffice? plus removeRow, I guess ... dunno. john
Re: top_y() is killing us
John Levon wrote: >> on LyXText::setHeightOfRow() would suffice? > > plus removeRow, I guess ... dunno. I'll make a try. Alfredo
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 03:52:52PM +0100, Alfredo Braunstein wrote: > I'll make a try. Alfredo Great ! john
Re: top_y() is killing us
I don't really read all of the mails arriving right now (there is just too much traffic), but I overscan all of them fast. Now I'm a bit worried about the actual state of the lyx developement are you all sure we will not end up as in the "old" development tree? I hope you try to hold on yourself and don't start changing stuff in too many places otherwise we will never be able to see what changes broke behaviour and we will therefore not be able to fix all of the newly introduced bugs. A bit worried, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
On Wed, Mar 19, 2003 at 05:14:49PM +0100, Juergen Vigna wrote: > I don't really read all of the mails arriving right now (there is just > too much traffic), but I overscan all of them fast. > > Now I'm a bit worried about the actual state of the lyx developement > are you all sure we will not end up as in the "old" development tree? We currently have : o the assert (bugs always there) o a new DEPM crash o some new drawing problems o slowdown of top_y() o anchor row setting on doc shorter than the workarea is not ideal That's as much as I'm really aware of. > broke behaviour and we will therefore not be able to fix all of the > newly introduced bugs. At the worst, we can do -D "1 week ago" -D "now" and go back. But I really don't think it will be necessary. regards, john
Re: top_y() is killing us
John Levon wrote: > o slowdown of top_y() > o anchor row setting on doc shorter than the workarea is not ideal These two are my bad but are pretty isolated and can be 'eliminated' by adding four lines to the existing code Btw, what's the problem with the second? Alfredo
