RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v7]

[Martin Fox]

On Mon, 10 Apr 2023 20:16:23 GMT, Martin Fox <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m line 473:
>> 
>>> 471:     // If the QWERTY key is in the layout sensitive area search the other keys in that
>>> 472:     // area. We may not find a key so returning NO is possible.
>>> 473:     for (unsigned short trialKey = 0x00; trialKey <= 0x7E; ++trialKey)
>> 
>> I see this as a last resource, in case everything else failed so far. But I wonder if this could be slow? 
>> Also given that keyCode in sensitive layout is true only for [0x00 - 0x32] and 0x5D, 0x5F, maybe you could improve this?
>
> This call is used by the Robot code and an accessibility feature (namely retrieving the `AXMenuItemCmdVirtualKey` property). Robots aren't built for speed but I will look into the accessibility side. To make significant gains in this code I would have to cache the results.

The accessibility code only calls `GetMacKey` for menu items which use `KeyCodes` and are not character-based (the check is `!isCmdCharBased` in MacAccessible.java). This means menu items where the accelerator references a key like `Return`, `Home`, or `PgUp`. `GetMacKey` will resolve these using the old lookup table without invoking the new, slower code that scans the rest of the keyboard. So accessibility shouldn't see a performance hit. A Robot will be slower to send events for some keys but I don't think that's an issue. Currently those are the only two clients of this call.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/425#discussion_r1164454567