Subject: Re: Bidirectional support
From: Thomas Fletcher (thomasf@qnx.com)
Date: Fri Dec 15 2000 - 09:54:26 CST
On Fri, 15 Dec 2000, Mike Nordell wrote:
> Tomas Frydrych wrote:
> > and it does impact the drawing performance at least a bit. What do
> > you guys think?
>
> The drawing performance is already horrible. Not to mention the quality. At
> least in Win32 the next line overwrites the bottom pixels from the previous
> line. This is most easily tested with spell checking turned on, writing
> jibberish that does get "squiggle", starting writing on a new line and watch
> those squiggles get partially overwritten. You can also find these errors by
> just typing "spell-legal" words, but where the glyphs overlap. The last one
> just writes over the previous one.
There are several things at work here. As Martin has already indicated,
we do in fact draw strings of text. The problem is that those strings
of text have to be converted for the "smart quote replacement" dohicky
thingamabob. So we pass in a buffer of UCS2 characters, then we have
to allocate a temporary buffer to to the translation of the characters
(with the remapGlyph stuff), then most of us end up having to convert
the UCS2 characters to a multibyte stream of UTF-8 characters. This
is all _just_ in the drawing code.
Moving up a level and taking a look at the whole "what happens when
you scroll" we have to iterate through almost the entire document even
if we are only looking at a page of the document. This "looking at
the document" involves running through and getting character width
calculations for the whole thing. The problem of course here is that
the character width information comes in two formats on _most_
platforms. There is the width of the actual glyph and then there
is the width which should be used for cursor positioning. We don't
discriminate between the two and this causes problems 1) In jitter
2) In the fact that our highlights clip chars.
Don't understand what I'm getting at ... take a look at:
http://qdn.qnx.com/support/docs/photon20/prog_guide/fonts.html
and more importantly:
http://qdn.qnx.com/support/docs/photon20/lib_ref/pf/pfextenttextcharpositions.html
One way to solve this problem (well I was only looking at the
clipping problem) would be to indicate in the drawChars
function return code whether the first and last characters
cause us to draw outside of the "width" of the string we
are asked to display.
In terms of an overal speed up ... yes AbiWord is a bit of a
dog when it comes to some operations. I have no doubt that
we can speed it up by intelligently caching values and losing
some of the iteration over characters in the document that
we are doing. It is a big project however.
> I think this displays a more serios problem we have, when displaying a line
> with a string (1 or more) characters of the same type (font and so on) we
> should bunch this together as a "writeText" operation, not write every char
> ourselves. That makes AW dog-slow (I know, I've been doing some performance
> tests).
As Martin mentioned we do (for the most part) bunch the
operations, there is still some extra bunching that could
be done however expecially when you are typing in new text.
Thomas
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Fri Dec 15 2000 - 09:51:26 CST