speed of testtext, directionality



Hi !

I spent a little effort trying to find out where pango wasts time.

#1: Font caching. 
> One thing that would help is to cache the font lookup on the
> PangoFont. The recently added Thai shaper should provide a good
> example of doing this.

I implemented this for the arabic shaper, but have not cleaned it up yet.
It does not seem to give much gain.
Maybe it would help more ( memory-wise ) to shape to allow the space
character to a 'native' arabic character, as it already is a native
'left-to-right' character ?
I can add the space character to the range of the arabic shaper, but that 
leads to normal text being handeled by the arabic shaper ( altogether, the arabic
shaper gets faster , being called less often ),
but altogether this is not such a good idea performance-wise.
There must be some better way of achieving this. 
Changing the PangoCoverage * wich  arabic_engine_get_coverage 
returns does not seem to help this issue.


#2: Strange behaviour of the arabic shaper when appending text to the end 
ot the line in left-to-right mode:
Actually, in this case, no shaping is done, and the characters do not 
appear ( Or only unshaped, if you have iso10646-1 encoded fonts ).
In this case, even though several arabic letters may have been typed,
any shaper's PangoAnalysis reveals that we are in a left-to-right run
of characters : analysis->level % 2 == 0 ! 
Amazingly enough, bidi-reordering is done correctly, but nontheless this
is wrong. Because of this, the arabic shaper in its current state falls 
back to not shape the letters. 
A workaround woud be to do reshaping in any case and not check the
level; but I'd rather like to find out why exactly the directionality
does not seem correct.

#3: One major speed issue:
When the cursor is moved, all the shapers are being called twice 
for the stuff on the current line and for which they are responsible.
This strikes me as strange, because:
*  If the cursor is really drawn on top of the rest, and is part of
   the layout, only one reshape ought to be needed.
   This is still true if I add a character, and the new string
   fits into the line after reshaping.
*  If the cursor is XOR'd on top of the string, cursor movement
   should not need to call for any reshape at all.


best regards, 

		Karl







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]