22/07/2013 15:10, Hashini Senaratne:
Even the difference is 3pix it gives totally a wrong scroll, even we can't
see the text cursor position.
Hello,
I think I know why this happens: have a look at this comment taken from
coordCache.h:
/**
* A BufferView dependent cache that allows us to come from an inset in
* a document to a position point and dimension on the screen.
* All points cached in this cache are only valid between subsequent
* updates. (x,y) == (0,0) is the upper left screen corner, x increases
* to the right, y increases downwords.
* The dimension part is built in BufferView::updateMetrics() and the
* diverse Inset::metrics() calls.
* The individual points are added at drawing time in
* BufferView::updateMetrics(). The math inset position are cached in
* the diverse InsetMathXXX::draw() calls and the in-text inset position
* are cached in RowPainter::paintInset().
* FIXME: For mathed, it would be nice if the insets did not saves their
* position themselves. That should be the duty of the containing math
* array.
*/
It says clearly that, while dimensions computed when computing metrics,
the positions are only computed at display time. I assume that, on your
system, giving focus to the window triggers a repaint.
Now the question is to know how to work around this problem. I would
appreciate if we could avoid to modify the way document display is done,
this would probably be out of scope for the project...
But once we know that the row has to be slid, we could maybe draw it a
first time (it is possible to draw without actually drawing) to get
positions, and then do it a second time. Or we need to find what is the
place where this update happens.
JMarc
