NEW 234058
Make FontCache::m_shouldMockBoldSystemFontForAccessibility static
https://bugs.webkit.org/show_bug.cgi?id=234058
Summary Make FontCache::m_shouldMockBoldSystemFontForAccessibility static
Cameron McCormack (:heycam)
Reported 2021-12-08 18:39:35 PST
Make FontCache::m_shouldMockBoldSystemFontForAccessibility static
Attachments
Patch (4.23 KB, patch)
2021-12-08 18:40 PST, Cameron McCormack (:heycam)
heycam: review?
Patch propagating to all FontCaches (4.41 KB, patch)
2021-12-10 00:12 PST, Cameron McCormack (:heycam)
mmaxfield: review+
Cameron McCormack (:heycam)
Comment 1 2021-12-08 18:40:35 PST
Myles C. Maxfield
Comment 2 2021-12-08 20:48:21 PST
Comment on attachment 446480 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=446480&action=review > Source/WebCore/platform/graphics/FontCache.h:151 > + static bool shouldMockBoldSystemFontForAccessibility() { return s_shouldMockBoldSystemFontForAccessibility; } don't you need to do a .load()? > Source/WebCore/platform/graphics/FontCache.h:199 > + static inline std::atomic<bool> s_shouldMockBoldSystemFontForAccessibility { false }; I think adding globals is kind of the wrong direction. There will already be multiple font caches; why can't a worker just read the (non-atomic) bool from its thread's font cache?
Cameron McCormack (:heycam)
Comment 3 2021-12-08 20:54:26 PST
(In reply to Myles C. Maxfield from comment #2) > Comment on attachment 446480 [details] > > Source/WebCore/platform/graphics/FontCache.h:151 > > + static bool shouldMockBoldSystemFontForAccessibility() { return s_shouldMockBoldSystemFontForAccessibility; } > > don't you need to do a .load()? std::atomic<T> has an operator T. > > Source/WebCore/platform/graphics/FontCache.h:199 > > + static inline std::atomic<bool> s_shouldMockBoldSystemFontForAccessibility { false }; > > I think adding globals is kind of the wrong direction. There will already be > multiple font caches; why can't a worker just read the (non-atomic) bool > from its thread's font cache? We can easily do that with the callOnAllFontCaches() function from bug 234060. But it seems overkill for a field that when set doesn't need any other special processing to happen.
Cameron McCormack (:heycam)
Comment 4 2021-12-08 20:55:54 PST
(In reply to Cameron McCormack (:heycam) from comment #3) > We can easily do that with the callOnAllFontCaches() function from bug > 234060. But it seems overkill for a field that when set doesn't need any > other special processing to happen. But I'm happy to change to use that if you prefer.
Myles C. Maxfield
Comment 5 2021-12-09 02:32:26 PST
Comment on attachment 446480 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=446480&action=review >>> Source/WebCore/platform/graphics/FontCache.h:199 >>> + static inline std::atomic<bool> s_shouldMockBoldSystemFontForAccessibility { false }; >> >> I think adding globals is kind of the wrong direction. There will already be multiple font caches; why can't a worker just read the (non-atomic) bool from its thread's font cache? > > We can easily do that with the callOnAllFontCaches() function from bug 234060. But it seems overkill for a field that when set doesn't need any other special processing to happen. I think that would be better. I'm also not sure if callOnAllFontCaches() is needed. Do you think that's better than just setting the current thread's value?
Cameron McCormack (:heycam)
Comment 6 2021-12-09 14:20:54 PST
(In reply to Myles C. Maxfield from comment #5) > I think that would be better. > > I'm also not sure if callOnAllFontCaches() is needed. Do you think that's > better than just setting the current thread's value? So you're saying: existing tests only need this value to be set on the main thread, and so we shouldn't bother propagating it to workers?
Myles C. Maxfield
Comment 7 2021-12-09 14:54:52 PST
(In reply to Cameron McCormack (:heycam) from comment #6) > (In reply to Myles C. Maxfield from comment #5) > > I'm also not sure if callOnAllFontCaches() is needed. Do you think that's > > better than just setting the current thread's value? > > So you're saying: existing tests only need this value to be set on the main > thread, Yes. > and so we shouldn't bother propagating it to workers? I wasn't going that far as to make a statement. I was just asking the question. If you think it should be set on all the threads because future tests may want that functionality, then sure, that makes sense. But I could also imagine a worker test that require the worker to call this function itself. I think it's up to you.
Cameron McCormack (:heycam)
Comment 8 2021-12-09 23:59:00 PST
(In reply to Myles C. Maxfield from comment #7) > I wasn't going that far as to make a statement. I was just asking the > question. If you think it should be set on all the threads because future > tests may want that functionality, then sure, that makes sense. But I could > also imagine a worker test that require the worker to call this function > itself. I think it's up to you. OK that's a fair point. Since this is set through Internals.settings, which feels like a global thing rather than a per-thread thing, I'm going to propagate to workers.
Cameron McCormack (:heycam)
Comment 9 2021-12-10 00:12:09 PST
Created attachment 446674 [details] Patch propagating to all FontCaches
Cameron McCormack (:heycam)
Comment 10 2021-12-10 00:12:50 PST
I really don't know that this is better than having a static variable that all FontCache instances can consult.
Radar WebKit Bug Importer
Comment 11 2021-12-15 18:40:18 PST
Ahmad Saleem
Comment 12 2023-06-12 16:34:15 PDT
*** Bug 234057 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.