Bug 215302

Summary: Update OriginalAdvancesForCharacterTreatedAsSpace to work correctly in the presence of inserted or removed glyphs
Product: WebKit Reporter: Myles C. Maxfield <mmaxfield>
Component: New BugsAssignee: Myles C. Maxfield <mmaxfield>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, dino, jonlee, koivisto, simon.fraser, thorton, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 215051    
Bug Blocks: 206208    
Attachments:
Description Flags
Patch darin: review+

Description Myles C. Maxfield 2020-08-07 16:40:12 PDT
Update OriginalAdvancesForCharacterTreatedAsSpace to work properly after r265241
Comment 1 Myles C. Maxfield 2020-08-07 16:45:26 PDT
Created attachment 406228 [details]
Patch
Comment 2 Darin Adler 2020-08-08 11:36:24 PDT
Comment on attachment 406228 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=406228&action=review

> Source/WebCore/ChangeLog:3
> +        Update OriginalAdvancesForCharacterTreatedAsSpace to work properly after r265241

"work properly" seems ambiguous

Do you mean "work without depending on something that’s been true in practice, but not guaranteed", "work more efficiently", "work in a way that’s more maintainable", or "work correctly"?

I’m assuming it’s the first. Can we find a slightly more precise way of saying that in the title, not just the change log comment?

> Source/WebCore/ChangeLog:11
> +        However, this is wrong, becuase shaping can insert or delete glyphs. Instead, now that we have

"becuase"

> Source/WebCore/platform/graphics/WidthIterator.cpp:61
>  public:

struct doesn’t need "public"

> Source/WebCore/platform/graphics/WidthIterator.cpp:73
> +    bool characterIsSpace = false;
> +    float advanceBeforeCharacter = 0;
> +    float advanceAtCharacter = 0;

In WebKit we’ve been using { false } instead of = false in cases like this.

> Source/WebCore/platform/graphics/WidthIterator.h:38
> +typedef HashMap<unsigned, OriginalAdvancesForCharacterTreatedAsSpace, DefaultHash<unsigned>, WTF::UnsignedWithZeroKeyHashTraits<unsigned>> CharactersTreatedAsSpace;

I think a sorted vector and std::binary_search might be better than a HashMap for this.

New code should use "using" instead of "typedef". Switch this since you are touching it, please.

What guarantees we never use 0xFFFFFFFE or 0xFFFFFFFF? If we need to stick with a HasMap, can we make this even more efficient by using 16 bits?
Comment 3 Darin Adler 2020-08-08 11:36:53 PDT
Comment on attachment 406228 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=406228&action=review

>> Source/WebCore/platform/graphics/WidthIterator.h:38
>> +typedef HashMap<unsigned, OriginalAdvancesForCharacterTreatedAsSpace, DefaultHash<unsigned>, WTF::UnsignedWithZeroKeyHashTraits<unsigned>> CharactersTreatedAsSpace;
> 
> I think a sorted vector and std::binary_search might be better than a HashMap for this.
> 
> New code should use "using" instead of "typedef". Switch this since you are touching it, please.
> 
> What guarantees we never use 0xFFFFFFFE or 0xFFFFFFFF? If we need to stick with a HasMap, can we make this even more efficient by using 16 bits?

I think I mean std::lower_bound.
Comment 4 Myles C. Maxfield 2020-08-09 00:36:29 PDT
Committed r265415: <https://trac.webkit.org/changeset/265415>
Comment 5 Radar WebKit Bug Importer 2020-08-09 00:37:21 PDT
<rdar://problem/66742090>