Does screen resolution or display scaling affect Katalon UI test reliability?

Web Testing
1

Hi everyone,

I had a question around screen resolution and display settings in Katalon tests.

If a test is created on a machine with a specific screen resolution and display scale (for example 2560×1600 at 200% scaling), does it need to be executed on the same resolution and scale to run reliably?

Could differences in resolution, DPI scaling, or other display settings cause tests to fail (for example due to click interception, element not clickable, or offset issues), even if the locators themselves are correct?

I’m trying to understand whether Katalon tests are resolution-independent as long as locators are stable, or if matching display settings between environments is recommended.

Any clarification or best practices would be appreciated. Thanks!

1 Like
2

Not necessarily.

It depends on the cases.

I don’t think your question makes good sense. You wouldn’t find any immediate YES/NO answer to your question.

Selenium allows users to simulate common activities performed by human as end-user; entering text into fields, selecting drop-down values and checking boxes, and clicking links in documents. Remember, you a human can operate only the web elements which are displayed and visible on browser’s window. A human can not click an invisible button.

Therefore, principally, Selenium requires the target element to be visible on the current view port of the browsers. This is the minimum requirement. If the element is out of the viewport and is NOT visible, then any click action by your test script would fail.

The sreen resolution or display scaling may or may not affect the visibility of each indivisual elements in your target HTML page. It depends on the way how your HTML/CSS/JS is coded. It depends on the way how your test case script is coded. It depends on too many factors so that it’s undeterministic.

Possibly you would want to learn WebUI.scrollToElement keyword

this would bring the target element to be visible in the viewport. You may want to use this defensively so that the view port is scrolled up/down so that the target element is visible before you click it.

3

Dot Per Inch (DPI) and screen resolution of the platform would affect significantly to the screenshots of browser you take. The following topic is an example how the device pixel ratio affects the screenshot and cause troubles for me.

If your test does something on screenshots, you must be careful screen resolution etc.

4

hi @alexpaglia89

in general, no, screen resolution and DPI scaling shouldn’t matter if your katalon tests are using proper DOM-based locators (XPath, CSS, attributes) and standard WebUI keywords

selenium interacts with elements in the DOM, not screen pixels, so tests are mostly resolution-independent

that said, display settings can cause issues if:

  • you use offset-based actions (clickOffset, drag by offset)
  • you rely on image-based testing (Sikuli)
  • the app has responsive layouts (elements move, collapse, or get covered)
  • high DPI scaling on Windows causes click interception or scroll issues

best practice:

  • avoid coordinate/image-based actions when possible
  • use stable locators + proper waits
  • set a fixed browser window/viewport size in setup (especially for CI)

so you don’t need to perfectly match resolution across machines, unless your tests depend on screen position or visuals

1 Like
5

Based on the Katalon documentation, resolution and display settings CAN impact test reliability, but the impact depends on your testing approach:

Key Findings:

For Visual Testing (Image Comparison):

  • :white_check_mark: Confirmed Issue: Resolution differences cause test failures even when the UI looks identical
  • According to the Katalon documentation on visual testing, when baseline and checkpoint images have different resolutions, Katalon detects them as mismatches
  • This is especially problematic with scrollable elements (calendars, tables) where the visible area changes between runs

For Element Locators (XPath, CSS, etc.):

  • :white_check_mark: Generally Resolution-Independent: Stable locators should work across different resolutions
  • However, offset-based clicks can be affected by resolution/scaling differences
  • Click interception issues can occur if overlays or other elements appear at different positions due to scaling

Root Cause

The issue is NOT with locators themselves, but with:

  1. Viewport/Screenshot Consistency: WebUI.setViewPortSize() may not apply consistently across environments with different OS display scaling
  2. DPI Scaling Effects: High DPI scaling (like your 200% example) can cause:
    • Different visible areas in screenshots
    • Offset-based click coordinates to be inaccurate
    • Overlay positioning changes
  3. Dynamic Content: Scrollable elements render differently based on available viewport space

Solutions & Best Practices

Solution 1: Standardize Viewport Size (Recommended for Visual Testing)

Step-by-step:

  1. Set an explicit, consistent viewport size before visual testing:

    WebUI.setViewPortSize(1920, 1080)

  2. Use Chrome headless mode to ensure consistent viewport behavior across environments:

    -browserType="Chrome (headless)"

  3. For scrollable content, ensure elements are fully visible before capturing:

    // Scroll element into view
WebDriver driver = DriverFactory.getWebDriver()
WebElement element = WebUiCommonHelper.findWebElement(testObject, 30)
((JavascriptExecutor) driver).executeScript("arguments[0].scrollIntoView();", element)

Source: Katalon Documentation - Fix Visual Testing Failures

Solution 2: Handle Click Interception Issues

If you encounter click failures due to resolution/scaling differences:

  1. Wait for element to be clickable:

    WebUI.waitForElementClickable(testObject, timeout)

  2. Use offset-based clicks if needed:

    WebUI.clickOffset(testObject, offsetX, offsetY)

    :warning: Note: Starting from Katalon Studio 10.3.0, offsets are calculated from the center of the element (not top-left), which is more consistent with W3C WebDriver specification.

Source: Katalon Documentation - Element Click Intercepted Exception

Solution 3: Override Display Settings at Runtime

You can override browser window size at runtime to ensure consistency:

import com.kms.katalon.core.configuration.RunConfiguration

// Set Chrome window size
RunConfiguration.setWebDriverPreferencesProperty("args", ["--window-size=1920,1080"])

Source: Katalon Documentation - Pass Desired Capabilities at Runtime

Best Practices Summary

Aspect Recommendation
Locators Use stable XPath/CSS selectors - these are resolution-independent
Visual Testing Always use WebUI.setViewPortSize() with fixed dimensions (e.g., 1920x1080)
Execution Environment Run tests in Chrome headless mode for consistent viewport behavior
DPI Scaling Avoid high DPI scaling (200%) in test execution environments; standardize to 100%
Dynamic Content Scroll elements into view before capturing screenshots
Click Actions Use WebUI.waitForElementClickable() before clicking to handle overlay issues

Conclusion

Your tests are NOT fully resolution-independent. While stable locators work across resolutions, visual testing and offset-based clicks are affected by resolution and DPI scaling differences. The best practice is to:

  1. Standardize the execution environment (same resolution, 100% DPI scaling)
  2. Use explicit viewport sizing in your tests
  3. Run in headless mode for consistency across machines
  4. Avoid offset-based clicks unless absolutely necessary

This ensures reliable test execution across different machines and environments.

1 Like
6

@alexpaglia89 Let us know if your query clarified and your implementation plan on screen resolution

7

Thanks a lot for the help! I suspect the 200% DPI scaling on my laptop to be the culprit. I’m going to look into my local setup and apply these defensive scripting methods to see if it stabilizes my results.

1 Like
8

Hey @Monty_Bagati — thanks for the detailed breakdown. I’d like to add some nuance because a few of these points conflate two very different things, which matters a lot for anyone trying to pick a strategy for their automation.

Quick intro for context : I’m Julien Mer, creator of OculiX, the modernized fork of SikuliX (the image-based automation project born at MIT CSAIL in 2009). I’ve been working on visual test automation for 20+ years, and OculiX is my attempt to bring the 15-year-old SikuliX codebase into the 2026 stack — Java 25, modern Recorder, MCP server, Paddle OCR, Tesseract, VNC/SSH/Citrix remote, Apple Silicon support. MIT license, actively maintained, and Katalon’s internal bundle of Sikuli 1.0.2 has been superseded by OculiX for a while now — relevant to one of your own “known limitations” in 11.0.0 release notes that explicitly mentions Sikuli 1.0.2 × Java 21 incompatibility. That’s literally fixed in OculiX because we are on Java 25.

Now to the technical points :

1. Image comparison ≠ image recognition. The whole post treats “visual testing” as one block. It isn’t. There are two fundamentally different techniques that get lumped together :

  • Visual regression testing (pixel-diff against a baseline) — à la Applitools, Percy, Katalon Visual Testing. This one IS resolution-sensitive because you’re comparing the whole viewport byte-by-byte.
  • Visual automation via template matching (OpenCV cross-correlation with similarity threshold) — à la SikuliX/OculiX. This one is NOT fundamentally resolution-sensitive. Similarity < 1.0 tolerates sub-pixel variance, scaling, anti-aliasing differences. Multi-scale matching (resize the template by ±20%) handles DPI scaling natively. Region-constrained search handles scrollable elements without a fixed viewport.

These are not the same technology and conflating them leads to advice that’s right for one and wrong for the other.

2. “XPath is resolution-independent” — true but irrelevant for the use cases that matter. The whole premise of visual automation is the scenarios where there is no DOM at all :

  • Citrix / RDP / ICA remote desktops (the actual thread context, I suspect)
  • Legacy Flash / Silverlight / Java Applet apps
  • Canvas-based apps (CAD tools, map viewers, games, dashboards, engineering software)
  • Electron / Unity / WPF native windows that expose nothing over accessibility trees
  • Mainframe 3270 emulators

None of these have XPath or CSS selectors. Recommending “use stable locators” doesn’t help because there are no locators. This is the exact niche where SikuliX/OculiX have been the default answer since 2009.

3. DPI scaling is handled at the framework level in mature visual tools, not worked around by the user. Telling users to “standardize 100% DPI, use headless Chrome, force 1920×1080” is a workflow constraint, not a framework solution. Proper visual automation abstracts this :

  • Pattern("x.png").similar(0.85) absorbs minor rendering differences from anti-aliasing and sub-pixel positioning.
  • Multi-scale matching resolves DPI scaling variance without user intervention.
  • OCR (Tesseract, PaddleOCR) is the orthogonal answer to “find this text” : screen-rendered text stays readable across resolutions much better than pixel-matching.
  • Region-of-interest constraints let you search inside a known window even if its position shifts.

In OculiX specifically, we expose all four primitives as MCP tools so any LLM agent can do visual navigation without caring about the underlying resolution.

4. Offset-based clicks are a last resort, not a recommended pattern. The whole Solution 2 section about WebUI.clickOffset(testObject, offsetX, offsetY) is the brittle path. A well-designed visual automation flow doesn’t click offsets from the element center — it captures a smaller, stable sub-image of the actual target button and clicks the match center. Completely resolution-adaptive by construction.

In practice, if someone is facing “tests break when I change screen resolution”, the question is rarely about “standardizing the environment” — it’s about the right tool for the job :

  • Standard web app with accessible DOM → locator-based ( Selenium, Playwright, Katalon Web UI ).
  • Remote desktop / no-DOM app / legacy UI / cross-OS visual flow → template-matching-based ( OculiX, SikuliX ).
  • Text-heavy UI where you want “click the button that says X” → OCR-based search (OculiX exposes this natively via the oculix_find_text MCP tool).

Mixing the wrong approach and the wrong tool is where resolution-fragility comes from, not from visual automation itself.

Happy to go deeper on any of these if you want and if Katalon is interested in updating its bundled SikuliX version past the 2015 vintage (your release notes hint at that being a pain point), we’re very open to collaboration. OculiX is MIT, so you could literally ship a fresh Java-25-compatible oculixapi.jar in your next release and the Sikuli 1.0.2 × Java 21 incompatibility goes away by itself.

Cheers.

Julien