On 03/10/2015 23:46, Jean-Marc Lasgouttes wrote:
Le 03/10/2015 11:50, Abdelrazak Younes a écrit :
I propose to get rid of pm::insetDimension.
pm is bv dependent; so it should nicely adapt to it containing bv.
I would think that bv::cordCache is bv dependent too...
Sure.
I do not understand your point here.
And currently something is wrong:
http://www.lyx.org/trac/ticket/9756
In this ticket you say pm is buffer dependent, this should not be the
case. Paragraphs are Buffer dependent and pms are bv dependent, this is
my point.
Obviously there is a bug here, is it only for SplitView? Or also for
mutiple windows?
I think you should keep pm::insetDimension and remove bv::coordCache
completely instead. Design should be in the end like this:
* bv contains one tm
* tm contains multiple pm (tm can refer to the top InsetText or not)
* pm contains multiple insetDimension, one per inset in the paragraph.
Note that:
* coordcache also contains dimensions and positions for inner math
insets.
MathInset should not be special in theory but, AFAIR, MathInset mixes up
the contents and the metrics and it was too difficult to split that like
for Paragraph and PM. This was also not fully necessary because
MathInsets do not adapt they form depending on the bv size.
In any case, I don't see why pm could not contains dimensions and
positions for inner math insets as well. A math inset is always inside a
paragraph or another math inset.
* having a global bv coordinate cache allows to know where a mouse
click lands (hovering, clicking...). It is doable with bv>tm>pm too,
but this defeats the idea of a good old cache.
AFAIU the only difference between the global bv cache and what I am
proposing is that the bv will ask its tm which will ask its pm which
will ask its inset metrics. But maybe I don't follow you.
SingleParUpdate would not be necessary if all elements did their job
correctly. I also guess that SingleParUpdate assumes that there is only
one InsetText, which is of course not true. We should aim to remove this
flag.
In some cases, I still believe that it makes sense for the code to
indicate that only the current paragraph has been changed. This is
something that the code cannot guess without rebreaking the paragraph
(which is expensive).
My point is that each insets or paragraph should know if something has
changed inside it. SingleParUpdate is a top->down mechanism because the
LFUN mechanism is always top down.
I guess it should be possible for each tm to ask its pms if it needs to
be recalculated. That's why I think the global SingleParUpdate flag
should not necessary.
On a related note, what is the semantics of a call to
Buffer::changed(false)? What does the caller mean?
That the buffer contents and only the content content is changed. I
guess this signal is abused for some other purpose.
I cannot parse your first sentence.
Buffer::changed(bool) means that buffer contents and only that.
And what does it means to have a buffer which contents is changed
without having updated metrics?
I don't remember exactly... maybe that this change is not visible and
thus doesn't need new metrics?
Couldn't this be done on demand? I suspect this could be
made transparent by doing it in the proper metrics-fetching method.
Maybe yes. You would have to assess if the on-demand computation does
not slow down the minimal scrolling case.
I do not really see how it could slow it down.
With the pre-computed pm you don't have to compute again if you stay
within the metrics limit of this paragraph when scrolling a bit.
Abdel.
