Subject: (longish) BeOS / Long strings drawing
From: Thomas Fletcher (thomasf@qnx.com)
Date: Thu Nov 16 2000 - 12:13:20 CST
On Thu, 16 Nov 2000, James Montgomerie wrote:
> ----- Original Message -----
> From: "Dom Lachowicz" <cinamod@hotmail.com>
> Subject: Re: Release Critical Bugs
> > >Basically what happens is that when entering text, copy & pasting text or
> > >loading a file
> > >the word wrapping runs into the margin. The text in the document appears
> > >properly (font / size etc..)
> > >but runs beyond the extent of the document into the background.
> > This I can confirm on Unix/Gnome. I have a couple of *huge* word documents
> > which exhibit this behavior. Also, they expose some wierd left-toolbar bug
> > where the toolbar is updated randomly/never while scrolling and only
> > properly after you click on a page. I'll publish these docs to my website
> so
> > people can take a look at them after class today.
>
> If it's the same bug as I've seen, it's much more extensive than that. It
> happened /all the time/ to me on BeOS (I don't have BeOS installed anywhere
> now, or I'd take a look and see if it was still the same).
A long time ago ... when the earth was green, the document
layout was not done on these scaled up values font values
but on the actual user selected font. Ie you were using
times 10pt and it would ask for the character metric of
times 10pt, do some work then ask you to draw a times 10pt
character. At this point dinosaurs roamed the earth and
the BeOS port properly respected its view borders and the
like.
Then to gain some accuracy these values were all scaled up.
I can't remember the exact reasons, or who did the work (I
have a feeling that it might even have been Dom .. the logs
would show it I'm sure). At this point in time things broke,
but then Daniel came along and fixed them ... at the same
time attacking the problem of jitter when you select text.
BeOS and QNX both have this problem where the width of the
character is not necessarily the placement of the next
character so if you draw characters rather than strings:
L, then u, then c, then y
as opposed to
Lucy
you un-doubtably will get jitter. Rather unfortunate that
the original design didn't take this into account ... but
oh well. Daniel decided to attach the jitter problem by
drawing all characters at the positions that Abi thought
they should be ... rather than as strings. This helped
matters greatly, though it was a significant slow down
(theoretically, in practice you probably don't even notice).
What is the point of all this? Well I just wanted to give
people an idea of where to look for the problem by giving
a rough sketch of what is going on on the BeOS port. The
best way of tackling this problem would no doubt be to trace
(debugger time) from key-press -> key handler -> data
formatting -> layout calculations -> graphics call and
see what could possibly go wrong. It _has_ to be something
with the character width generation (more likely) and/or
some bad assumptions in the layout code (less likely)
otherwise we would all be screaming.
I do occasionally get overruns which don't get re-drawn
properly, which I'm suspecting is entirely due to the
fact that some calculations internally assume that you
never ever get out of the box ... when in fact you do.
Happy hunting and good luck! I'll see about tracking
down the lack of update out of the box and may stumble
across your problem in the journey, but it won't be
today.
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 : Thu Nov 16 2000 - 12:10:58 CST