Repository navigation
Support DPI change in candidate/infolist window - #1481
Merged
Merged
Conversation
This is part of our ongoing effort to fully conform Per-Monitor DPI v2 protocol in Windows (google#831). With this commit, both the candidate window and the infolist window become fully aware of dynamic DPI changes. The indicator window and icons managed by text input processor (TIP) DLLs remain unchanged. The key implementation idea is to not rely on WM_DPICHANGED message [1]. It is really tempting to implement WM_DPICHANGED handler, but it turns out to be redundant for our use cases. Consider the following two cases explained in the WM_DPICHANGED message document [1]. 1. When the candidate/infolist window is moving into the monitor with a different DPI. In this case, win32::WindowManager should be aware of which monitor the candidate/infolist window will be displayed on, and can let the candidate/infolist window know the new DPI without relying on the WM_DPICHANGED message. 2. When the DPI of the current monitor changes while the candidate/infolist window is visible. In this case, the target application window typically re-renders to adapt to the new DPI, which then triggers a fresh layout pass on our candidate/infolist window. As explained above, win32::WindowManager always checks the DPI of the target monitor without relying on the WM_DPICHANGED message. Both cases arise because the candidate and infolist windows behave like popups anchored to the cursor location in the target application window; WM_DPICHANGED is primarily meaningful for top-level windows that users can drag and move across the monitors. Other than that, the implementation is rather straightforward: we just need to make sure to keep propagating the DPI information to the text renderer and to update the DPI-dependent resources when the DPI changes. Closes google#1459. [1]: https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
hiroyuki-komatsu
added a commit
that referenced
this pull request
Jun 24, 2026
3.33.6133 → 3.33.6239 Conversion: * Updated the OSS dictionary [975d7d6] * Updated Zip code data as of 2026-04-03 [3e72fb3] * Added the circled zero (⓪) to number conversion candidates (#1520) [b18e5de] * Updated words for font names (#1449) [335c3c9] * Removed trailing space after small final sigma symbol (#1450) [5154bd8] * Android: Improved the word prediction feature [40dc336, c692321, cb87ab5] * Android: Improted the user history prediction feature [7684d80, 3350a19, a8f29ae, c5dd76f] Features: * Added support for mathematical functions (sin, cos, etc.) in the calculator rewriter [27710f2] * Added text sanitizer against ill-formed UTF-8 and ASCII control characters [fa11e0a, 61bdcfc] * Windows: Supported DPI change in candidate/infolist window (#1481) [fafbde9] Bug fix: * Android: Fixed ClearHistory failing to delete candidates with leading spaces [a8f245e] * Emacs: Fixed candidate overlay collapse when tab-line is enabled (#1507) [0c8acf4] * Emacs: Fixed backward compatibility for candidate window display in mozc.el (#1427) [891e324] * macOS: Fixed a failure of application launch [34c3187] * macOS: Correctly set RGB values for footer border color [0b71173] Code: * Removed Singleton class usages (#1461, #1463, #1464, #1465, #1475, #1477, #1478, #1479, #1480, #1490, #1491, #1497, #1498, #1499, #1502, #1509, #1510, #1513, #1514, #1515, #1523) * Avoided unnecessary string-resizes by using absl::StringResizeAndOverwrite (#1524, #1525) [ff20a11, 6fce2f3] * Replaced const std::string& with absl::string_view across multiple modules [988fbca, a801e2f, edc7cd0, 99aa820, 8c82922, 7e648b2] * Refactored candidate view design and renderer styling using RendererStyle and renderer_style.textproto [751df90, be6dd36, 67cede2, afbf1d0] * Refactored FlatConcurrentCache memory footprint and insert API [c891133, 3a4130b] * Refactored UserPos cost mapping to generate kPosTypeStringTable dynamically from user_pos.def [53de4e4, 8c190e5, a20e4c1, 70fdb7f] * Decoupled ImmutableConverter and DictionaryInterface from ConversionRequest and extracted Options [2ee4da3, 6ba80c7, b30921c] * Refactored ConfigDialog UI layouts and frame mechanisms [4638ce6, c79a760, 895652c, 3c327d8] * Removed Lemon-based parser for CalculatorRewriter [cb95326, e96c1ba] * Removed Breakpad integration [1078e63] * Removed unused ServerLauncher::set_server_program (#1466) [a524a88] * Removed --timeout/--restricted from renderer (#1494) [be0eb82] * Removed an optional optimization for uniprocessor (#1501) [5381793] * Removed zstring_view [61068fe] * Fixed name shadowing in QtIpcServer constructor (#1486) [8cb8458] * Used unique service names in renderer_server_test (#1433) [858f8c0] * Made RendererStyleHandler platform-neutral (#1474) [e4cb300] * Applied standard code formatter to mac/ and unix/ directories [3024194] * Linux: Made the default Qt path relative to the workspace root [5d46097] * Linux: Removed generation of IBus engine XML and moved IBus config textproto to a dedicated file [2c84656, fb22406, dacc0a4] * macOS: Consolidated ios and macos selections into apple in mozc_select [96c86c0] * macOS: Made MacStatsConfigUtilImpl stateless (#1496) [5fc301c] * Windows: Simplified GetDPIScalingFactor for Windows (#1467) [04a1ed3] * Windows: Always used "en-US" in HResult::ToString() (#1476) [7c1f61c] * Windows: Fixed MSVC extension warnings in WinAPITestHelper (#1492) [8cb5cc3] * Windows: Defined NO_SHLWAPI_STRFCNS to not define StrCat (#1508) [fdfcc30] * Windows: Always evaluate ServerLauncher::server_program() (#1473) [45c33ae] Build: * Updated Bazel version to 9.0.2 [3ced4c8] * Removed git submodules [32be060, 48bbbf7, efaae55] * Moved src/data/version/mozc_version_template.bzl to src/version.bzl [68d04b2] * Made //engine:data_loader_test deterministic (#1522) [9afbd98] * Worked around QTBUG-145239 with a local patch (#1506) [9df9774] * Removed redundant build options from instructions (#1489) [180ef9f] * Android: Separated android_util into its own dedicated build target [060b96e] * Bazel: Made build rules compatible with Bazel 8.6 / 9.0 and updated external dependencies (#1451, #1453, #1454) [6c19ff0, 7cad196, 684c1d4, 979a650] * Windows: Allowed building Mozc with Visual Studio 2026 (#1495) [b940437] * Windows: Updated minimum Windows version to 1809 (build 17763) [3792d79] * Windows: Always used CustomAction to register COM DLLs (#1500) [82dca34] * Windows: Introduced mozc_win32_resource alias and universal MSI installer build support (#1434) [ecf3825, bab1403, 96bab12] * Windows: Used ARM64-native Ninja and LLVM binaries (#1382, #1460) [67e9d9e, 430ac03] * Registered Mozc Starlark macros with build_cleaner [e3e467e] PiperOrigin-RevId: 937168930
This was referenced Oct 30, 2026
hiroyuki-komatsu
pushed a commit
that referenced
this pull request
Nov 3, 2026
win32::WindowManager::UpdateLayout synced only the main window and the infolist window to the DPI of the target monitor, leaving the cascading window at its initial DPI. This should have been included in my #1481 [1] for #1459. Special thanks to Kirea413, whose #1604 helped us realize this issue. Closes #1609. [1]: fafbde9 PiperOrigin-RevId: 1012267390
PotatoSinology
pushed a commit
to marinaMoji/marinaMoji
that referenced
this pull request
Nov 7, 2026
win32::WindowManager::UpdateLayout synced only the main window and the infolist window to the DPI of the target monitor, leaving the cascading window at its initial DPI. This should have been included in my google#1481 [1] for google#1459. Special thanks to Kirea413, whose google#1604 helped us realize this issue. Closes google#1609. [1]: fafbde9 PiperOrigin-RevId: 1012267390 (cherry picked from commit c4ed468)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This is part of our ongoing effort to fully conform Per-Monitor DPI v2 protocol in Windows (#831).
With this commit, both the candidate window and the infolist window become fully aware of dynamic DPI changes. The indicator window and icons managed by text input processor (TIP) DLLs remain unchanged.
The key implementation idea is to not rely on
WM_DPICHANGEDmessage. It is really tempting to implementWM_DPICHANGEDhandler, but it turns out to be redundant for our use cases. Consider the following two cases explained in theWM_DPICHANGEDmessage document.When the candidate/infolist window is moving into the monitor with a different DPI. In this case,
win32::WindowManagershould be aware of which monitor the candidate/infolist window will be displayed on, and can let the candidate/infolist window know the new DPI without relying on theWM_DPICHANGEDmessage.When the DPI of the current monitor changes while the candidate/infolist window is visible. In this case, the target application window typically re-renders to adapt to the new DPI, which then triggers a fresh layout pass on our candidate/infolist window. As explained above,
win32::WindowManageralways checks the DPI of the target monitor without relying on theWM_DPICHANGEDmessage.Both cases arise because the candidate and infolist windows behave like popups anchored to the cursor location in the target application window;
WM_DPICHANGEDis primarily meaningful for top-level windows that users can drag and move across the monitors.Other than that, the implementation is rather straightforward: we just need to make sure to keep propagating the DPI information to the text renderer and to update the DPI-dependent resources when the DPI changes.
Closes #1459.
Issue IDs
Steps to test new behaviors (if any)