Bug 215302 - Update OriginalAdvancesForCharacterTreatedAsSpace to work correctly in the presence of inserted or removed glyphs
Summary: Update OriginalAdvancesForCharacterTreatedAsSpace to work correctly in the pr...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
Depends on: 215051
Blocks: 206208
  Show dependency treegraph
 
Reported: 2020-08-07 16:40 PDT by Myles C. Maxfield
Modified: 2020-08-09 00:37 PDT (History)
8 users (show)

See Also:


Attachments
Patch (5.78 KB, patch)
2020-08-07 16:45 PDT, Myles C. Maxfield
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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>