[p5.js 2.0 Bug Report]: WebGPU mode seems to have the coordinate system little off?

[msawired]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.2.0

Web browser and version

Chrome 143.0.7499.193

Operating system

MacOSX

Steps to reproduce this

In WebGPU mode, the coordinate system starts (0,0) from the center of the screen. Was this intended behavior?
If so, shouldn't mouseX and mouseY should reflect the (new) coordinate system position, such as (-10,-10)?

Steps:

1. See the sample sketch

Snippet:

async function setup() {
  await createCanvas(windowWidth, windowHeight, WEBGPU);
  // await createCanvas(windowWidth, windowHeight); //this works fine
}

function draw() {
	circle(0, 0, 20);
	circle(mouseX, mouseY, 20);
}

[msawired]

@davepagurek pinging you here.

[davepagurek]

WebGPU mode morks like WebGL mode where (0,0,0) is the center of the screen, so I think this is expected. Do you get the same behaviour in WebGL mode?

[msawired]

Sorry for my lack of knowledge; yes, it works the same on webgl mode. Then, shouldn’t mouseX, mouseY reflect the actual position the mouse is on? Sinan from OpenProcessing

…

On 15 Jan 2026, at 16:46, Dave Pagurek ***@***.***> wrote: davepagurek left a comment (processing/p5.js#8419) <#8419 (comment)> WebGPU mode morks like WebGL mode where (0,0,0) is the center of the screen, so I think this is expected. Do you get the same behaviour in WebGL mode? — Reply to this email directly, view it on GitHub <#8419 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENLWJSVWRWOAC7TXLKOV34G6Y7BAVCNFSM6AAAAACRZ3X7XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJVGQ4TQOJXGE>. You are receiving this because you authored the thread.

[davepagurek]

I feel like there's been some discussion of that in the past somewhere, although I can't find it at the moment -- I'll post an update if I do. But yeah having to do mouseX - width/2 and mouseY - height/2 is awkward for sure. I think the main reason it's still there is because changing it would break backwards compatibility with sketches, since from the start of webgl mode, the mouse coordinates have been in that coordinate space. @ksen0 @limzykenneth do you have any new thoughts on that?

[davepagurek]

Possibly we could treat mouse coordinate space as its own thing -- since it kinda is right now -- and encourage the use of screenToWorld more: https://beta.p5js.org/reference/p5/screentoworld/

This handles the webgl offset, but also when you're in a rotated coordinate space, manages that too.

Although there was some discussion in #7889 about how the "world" usage there is kinda incorrect and should probably be "object" for consistency, so that API isn't perfect either

[msawired]

I am sure you guys have put more thought about these matters together, that I am late to the topic. Given that, since this is v2.0 launch, I think it is safe to revisit some older concepts and revise them for future new-user experiences. If the only purpose of keeping mouseX and mouseY on page coordinates is to backwards compatibility, it could be foregone in this version. Because, experiencing this inconsistency as a new user in the future will be harder to deal with, then asking legacy users to adjust when they update the library on their sketches. Also, once v2 is default, I can imagine there will be lots of 2D-like sketches using WebGPU, just for the sake of speed it brings (think q5js). It would be very off to ask these users assume a 3D coordinate system (along the still-2D ones like mouseX). I guess, I believe consistency within the system is more important than providing backwards compatibility, particularly on major launches.

…

On 15 Jan 2026, at 19:35, Dave Pagurek ***@***.***> wrote: davepagurek left a comment (processing/p5.js#8419) <#8419 (comment)> Possibly we could treat mouse coordinate space as its own thing -- since it kinda is right now -- and encourage the use of screenToWorld more: https://beta.p5js.org/reference/p5/screentoworld/ This handles the webgl offset, but also when you're in a rotated coordinate space, manages that too. Although there was some discussion in #7889 <#7889> about how the "world" usage there is kinda incorrect and should probably be "object" for consistency, so that API isn't perfect either — Reply to this email directly, view it on GitHub <#8419 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENLWJGABWCA34IA2MVXGT4G7MXLAVCNFSM6AAAAACRZ3X7XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJWGMYTKMJUGY>. You are receiving this because you authored the thread.

[VANSH3104]

I also want to make a point in favor of keeping the current behavior.
The difference between screen coordinates and world coordinates is actually a really important concept in 3D graphics, and hiding that distinction might make things easier at first but would ultimately hide how these systems actually work. The screenToWorld() function already gives us a clean way to handle this conversion when we need it, and keeping things consistent between WebGL and WebGPU makes sense for developers moving between the two.

[limzykenneth]

For me, using screenToWorld is definitely more encouraged, it can be used with let localMouse = screenToWorld(mouseX, mouseY).

Some of the problem with this here is first, having mouseX/Y have different behavior in WebGL/WebGPU creates explicit dependency between the WebGL/WebGPU module and the events module. In general with the new module structure I'd like to avoid this as much as possible (there could be future implementation where the events modules is not included or the WebGPU module is used outside of the browser environment and cannot expect browser mouse events to exist). There are ways of implementing this that take into account this dependency but I feel it is brittle.

Secondly, expecting mouseX/Y to have origin in the middle of the canvas is a departure from the nature of the sketch canvas existing in the DOM. As mouseX/Y reads coordinates from the DOM API, that must read from the top left corner, one result of this is that mouseX/Y has a value outside of the canvas which a user can be expected to perhaps use (eg. getting relative position of something else in relation to the canvas). Doing a translation will make that somewhat inconsistent, and can cause confusion when someone is trying to position their sketch using top left coordinate as common in HTML/CSS and having variable size canvas such as doing something responsive. In short, keeping existing behavior gives more compatibility when a user is working with the DOM.

As @VANSH3104 just mentioned above, screen to world is an important concept in 3D graphics and is common throughout game engines, the WebGPU mode should be seen more like a 3D mode than a 2D mode with "better performance". If there is a desire for 2D mode with WebGPU backend, it should be a separate renderer that is implemented to be so, ie. the origin for drawing should be at the top left already and there should not be any perspective kind of drawing, not unlike what PixiJS does.

What we can, if really needed, is to have a pair of variables that already does let localMouse = screenToWorld(mouseX, mouseY) exposed to the user like worldMouseX/Y.

[limzykenneth]

I think it is worth to mention that I can see the intuitiveness of having something like circle(mouseX, mouseY, 50) automatically creates a circle that follows the mouse and potential usage such as a kind of custom cursor. It works just as well in Processing although Processing does not need to account for the larger context the sketch exist in such as the existence and the model of the DOM. I just want to make sure that we are not trading one set of intuitiveness for another set of hard restrictions we find ourselves in somewhere down the line.

[msawired]

Hmm, I see your point(s). I also did some tests to see how mouseX/Y behaves on other situations (such as after translate, etc.). I guess this is my UX designer in me thinking more from user intention point-of-view, particularly within the ethos of Processing/p5js simplifying the computational norms towards a more visual arts perspective. When a user types `circle(mouseX, mouseY, 20)`, I see it as they intend to put a circle where the mouse is (not necessarily "where the mouse is positioned per canvas"). But I see that the behavior of mouseX/Y was never coded that way (such as, it doesn’t reflect the real mouse position after a translate), so probably it wouldn’t be worth to change its existing paradigm for WEBGPU. Canvas position it is. I didn’t know about v2 screenToWorld function, pretty cool. Is there a reason why rotate acts pretty different in WEBGPU than WEBGL? https://openprocessing.org/sketch/2848716 I guess the WebGPU 3D world acts quite differently than WebGL. I need to read about this more. Thank you for all the clarifications and sharing your thoughts.

…

On 16 Jan 2026, at 13:40, Kenneth Lim ***@***.***> wrote: limzykenneth left a comment (processing/p5.js#8419) <#8419 (comment)> I think it is worth to mention that I can see the intuitiveness of having something like circle(mouseX, mouseY, 50) automatically creates a circle that follows the mouse and potential usage such as a kind of custom cursor. It works just as well in Processing although Processing does not need to account for the larger context the sketch exist in such as the existence and the model of the DOM. I just want to make sure that we are not trading one set of intuitiveness for another set of hard restrictions we find ourselves in somewhere down the line. — Reply to this email directly, view it on GitHub <#8419 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENLWL65MTREOYKMA4LCDT4HDL3BAVCNFSM6AAAAACRZ3X7XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJZHA2TGNRWHE>. You are receiving this because you authored the thread.

[davepagurek]

Thats a bug! Looks like if I add a manual push() and pop() around the whole draw, then it starts behaving that way again. I'll look into a fix soon!

[davepagurek]

Just put up a PR (#8423) for the above. In general if you see any transformation things working differently than in WebGL mode, that's a bug -- the intention is to have things behave equivalently.