I really like the effort you put into cleaning up the mess.

I have briefly looked at this code in the past and it is quite convoluted
and hard to understand what and where settings get set.
I tried to hunt down a issue in the Etoys image that a bug can cause
certain characters to change color when the image get in a shaky state.
(which happens quite often when I test ideas)

Karl




On Sat, Sep 21, 2013 at 5:08 AM, tim Rowledge <tim at rowledge.org> wrote:

> OK, after a couple of weeks rewriting how Scratch draws tiles I'm back to
> looking at dear old scanners and fonts.
>
> After side-by-side comparing the old scanners  with the new 'Multi'
> scanners, my conclusion is that there is *very* little difference and we
> really ought to be able to go back to a single set of classes. Which, I
> claim, would be nice, since we've already visibly suffered from the obvious
> side-effect of having two trees as bug fixes get added to only one part.
>
> So far as I could tell the only substantive difference relates to the use
> of the presentation/presentationLine ivars which seems to be not very
> important (ref Yoshiki's message 8 sept) and even seems to be mostly
> inactive (ref nice's message regarding  Multilingual-nice.116 same date).
> It would be really nice to get a solid decision on whether it is still
> wanted, or should be removed, or if it needs some fixes that can be
> provided.
>
> I'm puzzled by quite a few things I've discovered.
>
> a) There are {language}environment classes and encoding classes. There is
> #isBreakableAt:in: implemented in both but seemingly unused in the encoding
> classes because it is just plain broken there. Should it be removed from
> the encoders? In the language environment classes it is implemented to
> return true for space and cr by default, but space, cr & lf in Latin1 and
> Latin2. Is that as expected?
>
> b) MultiCharacterScanner>setConditionArray: cuts out the handling of
> #space - any ideas why?
>
> c) as previously mentioned MultiCharacterScanner>addCharToPresentation: is
> currently unused, apparently because of issues with Unicode &
> #scanMultiCharactersCombiningFrom:to:in:rightX:stopConditions:kern:  - do
> we have any decent hope of a fix?
>
> d) MultiCanvasCharacterScanner>setFont uses baselineY differently to its
> CanvasCharacterScanner equivalent; why?
>
> e) TextComposer>composeLinesFrom:to:delta:into:…. differs minimally from
> MultiTextComposer>multiComposeLinesFrom:to:delta:into:…. and is the only
> sender of #canComputeDefaultLineHeight. What is the intent? Is this just a
> bug fix added in one place and not the other?
>
> f) one of the oddest - DisplayScanner>displayLine:offset:leftInRun: passes
> the displayString:.. to the font (which I see as good) but
> MultiDisplayScanner uses the bitlblt instead which seems quite wrong.
>
> That'll do for now. I hope we can get some information together to allow
> this to be improved since it should really simplify an important area of
> code that gets a lot of exercise and needs to be as fast as possible. I
> know most of you are running 128 core 75GHz machines with  42Tb of ram and
> so on, so it hardly matters, but there are over a million Pi's trying to
> run Scratch that need help. And there will almost certainly be *many*
> millions more trying to use Scratch and Squeak over the next year or so,
> scattered across parts of the world where a Pi is more computer than anyone
> could have imagined a year ago - Pi is probably going to be *the* platform
> in sub-Saharn Africa and much of Asia. Let's at least try to make it good,
> eh? This is what Smalltalk has always claimed to be about.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: AGO: Allow Games Only
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130922/07d21777/attachment.htm