I see that, but doubles won’t help you here. Xojo controls, as previously mentioned, only use integers. So you need to use integers. You can assign a double to an integer, but Xojo will just drop the decimal place. Rounding won’t help either, because 1200/7 = 171.42 which rounds to 171, and will result in a total width of 1197. Just one pixel wider (1201/7 = 172.57) will round up to 172, which will mean a total width of 1204. No matter what, you’ll always end up at a multiple of 7 and either draw too narrow or too wide. If you want it perfect, you need to do something with the remainder. There’s no magic bullet to handle that for you.
It all depends on the grade of approximation applied to rounding, For ex. we’ll never get an acceptable cirfumference lenght rounding π 3.14 to 3 but we can achieve it using 3.14 which actually is 3,14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 58209 74944 59230 78164 06286 20899 86280 34825 34211 70679.
Supposing Xojo remembers by default a value using decimals then it’s obvious the rendering needs an automatic method of compensation when > destination absolute value = 1200 > Assuming 1200/ 7 = x While x * 7 = 1200.
BUT the compensation more precise more the rounding is precise.
Determining x (for graphic circumstance) needs a method of compensation by default based on the use of pixels = limitation. That’s what I’m saying.
Do you agree with me?
Sorry, I do not. At the end of the day, there is still a whole number of pixels on the screen. You do not want to try to draw at a partial pixel. I actually wrote about the topic at The ZAZ: Precise Drawing With Doubles. Doubles are not a magic solution. I think you should trust me on this one. When it comes to drawing in Xojo, there are few that can offer as experienced advice as I can. I’ve been doing this for around 20 years, and I wrote Xojo’s layout editor, navigator, library, and toolbars. I have a lot of experience in the subject, and approximating is going to give you either incorrect or blurry results. The only way to avoid that is not to approximate in the first place.
1 Like
Using a more precise value while compensating it result that for ex.
1200/ 7 = x = 171,42
If the auto-compensation method would be based on the rounding to 171,42 instead of 171 it may implicitly contain the key for the best compensation wich anyway - you’re right on this point - would be:
Compensation to be managed = ( 1200 (as absolute destination value) - 171 x 7 ) / 7 Method to manage dyscrepancy*
Method to assign dyscrepancy better to be based on value ,42
You’re right, you’d get good results rounding to two decimal places. But in the real world, that’s not an option. In the real world, Xojo controls are always drawn to whole numbers.
That’s why…
