RESOLVED FIXED Bug 215302
Update OriginalAdvancesForCharacterTreatedAsSpace to work correctly in the presence of inserted or removed glyphs
https://bugs.webkit.org/show_bug.cgi?id=215302
Summary Update OriginalAdvancesForCharacterTreatedAsSpace to work correctly in the pr...
Myles C. Maxfield
Reported 2020-08-07 16:40:12 PDT
Update OriginalAdvancesForCharacterTreatedAsSpace to work properly after r265241
Attachments
Patch (5.78 KB, patch)
2020-08-07 16:45 PDT, Myles C. Maxfield
darin: review+
Myles C. Maxfield
Comment 1 2020-08-07 16:45:26 PDT
Darin Adler
Comment 2 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?
Darin Adler
Comment 3 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.
Myles C. Maxfield
Comment 4 2020-08-09 00:36:29 PDT
Radar WebKit Bug Importer
Comment 5 2020-08-09 00:37:21 PDT
Note You need to log in before you can comment on or make changes to this bug.