Skip to content

Conversation

GoodBoyDigital
Copy link
Member

@GoodBoyDigital GoodBoyDigital commented May 2, 2025

Description of change

This change fixes an issue in DOMPipe where DOMContainerelements would not be positioned correctly if the parent canvas element was scaled using CSS properties like width or height.

Previously, the container div for DOM elements was only translated based on the canvas offsetLeft and offsetTop. This fix introduces scaling to the container div's transform. The scale factor is calculated based on the ratio of the canvas's CSS style.height to its canvas.height, multiplied by the renderer's resolution. This ensures that the DOM elements align correctly with the PixiJS scene, even when the canvas itself is scaled via CSS.

Pre-Merge Checklist
  • Tests and/or benchmarks are included
  • Documentation is changed or added
  • Lint process passed (npm run lint)
  • Tests passed (npm run test)

@GoodBoyDigital GoodBoyDigital requested review from Copilot and Zyie May 2, 2025 11:58
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes the incorrect positioning of DOM elements on a scaled canvas by incorporating a scale factor into the transform.

  • Updated the transform style to combine translation and scaling
  • Calculated the scale factor based on canvas CSS height, actual height, and renderer resolution

Copy link

codesandbox-ci bot commented May 2, 2025

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Comment on lines 125 to 128
const scale = (parseFloat(canvas.style.height) / canvas.height) * this._renderer.resolution;

// scale according to the canvas scale and translate
this._domElement.style.transform = `translate(${canvas.offsetLeft}px, ${canvas.offsetTop}px) scale(${scale})`;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not need to also check the width here?

const scaleX = (parseFloat(canvas.style.width) / canvas.width) * this._renderer.resolution;
const scaleY = (parseFloat(canvas.style.height) / canvas.height) * this._renderer.resolution;

// scale according to the canvas scale and translate
this._domElement.style.transform = `translate(${canvas.offsetLeft}px, ${canvas.offsetTop}px) scale(${scaleX}, ${scaleY})`;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we 100% should !

@Zyie
Copy link
Member

Zyie commented May 4, 2025

Could we have a test for this?

@GoodBoyDigital
Copy link
Member Author

Could we have a test for this?

yes! test added 👍

@GoodBoyDigital GoodBoyDigital requested a review from Zyie May 8, 2025 17:20
@Zyie Zyie added the ✅ Ready To Merge Helpful when issues are in the queue waiting to get merged. This means the PR is completed and has t label May 9, 2025
@Zyie Zyie added this pull request to the merge queue May 9, 2025
Merged via the queue into dev with commit 8f9f7fd May 9, 2025
5 checks passed
@Zyie Zyie deleted the fix/dom-container-scale branch May 9, 2025 10:29
@Ralalu
Copy link

Ralalu commented May 24, 2025

It would be great if the DOMPipe allowed customizing the z-index of the overlay container.

Right now it's hardcoded to 1000, which cause layering issues in my app (e.g. with rc-Dock floating panels).

Suggested improvement:
Allow passing an optional zIndex via constructor or static default.

Current workaround:

const domContainer = document.querySelector('div[style*="z-index: 1000"]');
if (domContainer) {
  (domContainer as HTMLElement).style.zIndex = '10';
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✅ Ready To Merge Helpful when issues are in the queue waiting to get merged. This means the PR is completed and has t
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants