I am very confused about how this works. I always thought about pixels as whole numbers, and I was writing my game having this constantly in mind. I thought, okay this has to work with whole numbers, I can’t have decimals because it will just round it when I draw things, so it will not be accurate. This wrecked my brain. However, then I thought okay let’s just forget pixels and think as if I could draw things with decimal accuracy, just to see what it would look like on the canvas, and what do you know, it worked exactly how I wanted it to work. I am very curious if anyone knows how this is possible?
1 Like
I’m pretty sure it just truncates the value, so e.g. 42.375 would just be treated as 42 when it’s drawn to the screen.
You could test this yourself by creating a sketch that draws two points: one at 50, 50 and another at 50.1, 50.1, and then zooming in to see if there’s any difference.
1 Like
Thats what I assume as well, yes. But the way my code works at the moment is like this:
current x,y position is incremented by a very small number, calculated using trigonometry. So, I want the next x,y position to be diagonally always at 1.5 pixel distance away from the old x,y position, so using trigonometry I find what the change in x and y should be, which usually varies around 1.0-1.2. And my code works perfect, it totally makes a distinction in direction depending on a radius i choose. This makes no sense to me because I would say 1.0-1.2 always rounds down to 1.0, so there shouldnt be a diagonal movement (besides the one diagonal which is, x+1 and y+1) but there is every diagonal you would want… how is this possible?
1 Like
possibly the
https://processing.org/reference/pixelDensity_.html
and the
https://processing.org/reference/smooth_.html
not make it a pure INT thing we would think of first.
for p5.js must be something similar??
that’s interesting. What does changing the pixelDensity do exactly? I dont quite understand, as it just says “makes it possible for Processing to render using all of the pixels on high resolutions screens”. I mean, what is it by default? Do we not have pixel-control over the screen? is it an illusion?
i not suggested changing,
check with
displayDensity()
//and
pixelDensity()
my idea was just to say that if you think you control 1 pix,
it might be with pixelDensity = 2
actually 4 screen pixel
what you can check if they have one or 4 different colors.
https://p5js.org/reference/#/p5/pixels
( but i am not sure if i have the right understanding )
both display and pixel density are 1, checked 
1 Like
can you show your problem code in
https://editor.p5js.org/
https://editor.p5js.org/kll/sketches/hVpA0TjGL
something like i see that line width is repeatedly changing?
by the way pls test strokeWeight(0.5)
how that fits into any pixel thinking?
I have no problem in my code, my code works perfect (because I stopped thinking about pixels in whole numbers)! I just want to know how P5 or JS handles drawing ‘decimally’ on the canvas
I made an example to show that shows that decimals matter:
https://editor.p5js.org/Milky/sketches/bKgbyQi_p
All versions of the Processing API use fractional pixel coordinates internally - p5.js, Processing(Java), Processing.py, Processing.R etc. This is true for all forms of drawing (rect, ellipse, line, point, PShape, etc. etc.), not just text.
Here is a simple “slow text follows mouse” demo sketch in p5.js:
Ability to express fractional pixels is also built in to browser-based javascript rendering and to CSS.
https://www.simonbattersby.com/blog/browsers-and-fractional-pixels/
However, how those get expressed during rendering was for a long time an implementation detail of different browsers:
https://cruft.io/posts/percentage-calculations-in-ie/
As screens (even small ones) increase in size / pixel density and as devices increase in processing power, the general trend is towards all contemporary browsers using sub-pixel rendering.
2 Likes