Subject: Re: More Bidi patch comments - everybody please read
From: Jesper Skov (jskov@redhat.com)
Date: Mon Jan 01 2001 - 06:01:32 CST
>>>>> "Tomas" == Tomas Frydrych <tomas@frydrych.uklinux.net> writes:
>> OK, some overall (hard) questions:
>>
>> o What does it mean to split the carret? I haven't tried the code,
>> but will tomorrow. Would be good with an explanation in words
>> though.
[description snipped - thanks]
>> o Finally, what is the code size and performance overhead of just
>> making BiDi The Way AbiWord works? Get rid of all the conditional
>> code that makes maintainment and understanding harder.
Tomas> I would be for, but I cannot judge the performance loss, my
Tomas> machine is too fast, and the BiDi processing does adds quite a
Tomas> bit of overhead.
I'm almost sure that for usage where BiDi is not used, there should be
almost no overhead. And we should even be able to streamline the code
to get a fast path for default one-direction-only usage, as Thomas
suggested.
This is one of these cases where it'd be great if we had some means of
automatic testing, comparing times taken to "write in" a text, making
some changes etc., between the regular and BiDi-enabled build.
Anyone here who has experience with expect?
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).
Basically, I'm sure there's a lot of reasonable and sound changes we
can make to the existing code which will make it acceptable for a
default implementation. It's something we can explore - I don't
pretend to have the final answer here :)
Jesper
This archive was generated by hypermail 2b25 : Mon Jan 01 2001 - 06:01:43 CST