Here is the demo:
If you look at the first rectangle, it’s always jittering.And the second is not jittering.Are there any issues with the accuracy of numerical processing？
cc @amoebachant
Thanks for the report and the repro @RichardFly - I’m away today and tomorrow but I’ll take a look at this on Wednesday. Thanks again!
1 Like
Any news ?
Was working on your other bug report 
I’m taking a look at this one now…
Hi @RichardFly, for this one, the problem is that the top/left/width/height values the playground was using were not pixel aligned, so when the top left rectangle rect calculated its left value, it was taking the fixed (non-pixel aligned) value and subtracting width, another non-pixel aligned value. That plus the non-pixel aligned width meant that the right edge of the box wasn’t always going to line up with the expected pixel.
In this updated playground, I’m pixel aligning the values by using fractions of the render height and width: https://playground.babylonjs.com/?inspectorv2=true#XCPP9Y#23494
I’d recommend taking pixel alignment into account in your project so that you don’t get unexpected results when you UI falls between pixels.
I hope that helps!
Maybe it’s not that helpful.The demo in playground is just an example of my use case.Typically,in a 2D editor, a rectangle used for selecting elements or controls is a quite normal thing. Usually the rectangle will be fixed a start pointer point, and it’s width , height and position will be changed during the pointer move . So the fixed point will be non-pixel aligned as what you said, the increment too.
I don’t think that require user to input the pixel aligned value would be a reasonable solution. Maybe it’s an internal process problem, right?
Hi @RichardFly, if you’re looking to build a 2D GUI with a selection box that is controlled by the mouse, you could use the scene.pointerX and pointerY properties to get pixel aligned values and use those to draw the rectangle. Here’s a sample I put together: Babylon.js Playground
Does that help with what you want to do?
Thanks!
Yeah, the implementation code in the playground is basically the same as mine. But have you noticed that if your mouse move to the top left of the start point, you will notice that the bottom right of the rectangle was jittering, that’s why i made the demo in the playground.
Plus, the demo in your playground, if your mouse moves to the bottom right of the start point, the top left of the rectangle is stable.What I want to say is that maybe the internal process of evaluate floats value met some problems.
I am using mac edge. I could still repro the jittering problem in your playground.
Ah, I wasn’t seeing the jitter in my PG until I realized you’re running on Mac and that you probably have a display scaling factor greater than 100%. I just tried my PG again with my scale factor increased and I do see the jitter in my PG too - a good clue! I’ll dig in further, thanks for the hint!
1 Like
Hey @RichardFly, with this new repro I was able to observe the values that rectangle.ts is passing into context.strokeRect() jittering, and worked backwards to find that in control.ts the size of the control was getting converted to an int. I believe that truncation is what was causing the math to be wrong that eventually leads to calling strokeRect() with the wrong values. As an experiment, I temporarily removed that conversion to int and it seems like that did stop the issue from repro’ing. To double check, could you try out this playground from a temporary draft PR I created to see if it stops repro’ing for you as well? I’m not proposing this as the fix, but it would be super helpful to know if it does stop the repro for you as well.
Thanks, and have a great weekend!
I tried it. It works! No more jitter. Thanks.
Great, that’s really helpful information. I’ll work on a proper fix on Monday. Appreciate the report and all of the help getting the info we needed to isolate the problem!
Hi @RichardFly, after more testing today I have merged the PR with that fix. Thanks for the bug report!