On Mon, 10 Apr 2023 20:16:23 GMT, Martin Fox <d...@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
