Subject: Re: More Bidi patch comments - everybody please read
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Jan 02 2001 - 03:35:41 CST
Hi Jesper (and others),
> Implementation wise, I wonder if we could simplify things by not
> having (x, y, x2, y2) functions in all classes for findCoordPoint
> since that is a heavily used function.
>
> Would an alternative of (x, y, direction) be viable? findCoordPoint
> would need to be called twice on borders between runs of two different
> directions to find first one, then the other insertion point. And when
> we get some caching in place to avoid the function scanning from the
> top of the document each time, I think performance impact will be
> negligible while still providing a fairly clean abstraction (i.e., the
> code that needs to handle drawing of two distinct carrets might as
> well call findCoordPoint twice when necessary instead of requiring
> findCoordPoint to always explicitly doing the extra calculations).
>
(This has turned up to be quite long, but please read it all)
That would certainly be possible (anything is possible), whether it
would make things easier or more complicated I am not sure. The
code that hadles the drawing is fv_View::_xorInsertionPoint, but
only the findPointCoords of an actual run is in position to decide
whether 1 or 2 carets are needed. _xorInsertionPoint actually does
not call findPointsCoords, it uses the members m_yPoint,
m_xPoint (and m_xPoint2, m_yPoint2 for bidi). Thus, either you
would have to include the call to findPointsCoords inside
_xorInsertion, which is most undesirable considering the frequency
with which this is called, or make sure that the code responsible
for setting m_xPoint, m_yPoint sets m_xPoint2, m_yPoint2 as
well; to ensure that you do not call it twice when not needed you
will have to include some logic for findPointCoords to determine
whether this is the first or second call, and in return some way to
indicate on the return of the first call whether a second call is
needed. In other words ther first call to _findPointCoords will have
to do almost everything that the (x,y,x2.y2,dir) version does in
order to determine whether to ask for itself to be called again, and
the second call will have to do quite a bit of this again. Thus, we
will end up with mechanism which is unlikely to be more efficient,
and is going to completely obscure what is really going on.
What I am really trying to say is that a bidi insertion point really
has 4 coordinances and to pretend it does not, is going to confuse
things, not to clarify. The thing is that probably most of the calls to
findPointCoords that currently ignore the second set of
coordinances will need it in the end, I just have not got to it (i.e.,
scrolling will have to deal with the two points on diferent pages,
etc.).
Also, as I recall doing the modifications, findPointCoords is not
called in a great variety of situations or that often. This merely
looks like it because the calls to the run's function are chained
through the functions of classses that stand between it and the
View. If I am not mistaken this function is not used for anything
alse than working out the coords of the insertion point, and thus I
think it really needs to have a four-coordinace signature.
I think the fast tracking that Thomas suggested will really need to
be done with regards to fp_Line::_createMapOfRuns, for if we can
selectively bypass the processing this function does, wel will end
up with code that is only very slightly slower that the plain uni-
directional version.
Tomas
This archive was generated by hypermail 2b25 : Tue Jan 02 2001 - 03:40:33 CST