Odd problem matching sprite height to canvas

Maybe the component should store the original DP value in a variable and return it instead of recalculating each time?

Thank you all again for enlightening me.

I think for my app to work predictably and how I want it to, I have to specify that the user use a tablet with a dpi of 160 or 320 so that each pixel, or every 2 pixels can be used reliably for my measurement scheme. This is really a project for myself and I don't intend to sell the app, so I think that is reasonable. Luckily my old tablet is 160, so I should be set.

Thank you again.

I don't buy that Himanshu because we are talking about items of identical dimension, therefore any transformation from integer to float should give the same result. It is doing so on two devices (out of three tested)

@ChrisWard Let me explain I got solution there is a bug in the App Inventor Source,

Test Device: Lenovo Tab
Device Density: 1.5
Example Height = 399

Bug
I set the height of the Canvas component to 399 in Designer Property but get 398 from the block.

Mathematics Behind the Scenes
Designer Property Value = 399
DP = 399
PX = 399 * 1.5 = 598.5 (598 after casting, this is actule value set to Canvas Height)

component_set_get
after performing Do It on this block I got 398 because the App inventor return value into DP.
DP = 598 / 1.5 = 398.66666 = 398(after casting see below code)

You can also see this in this video

If Video is not visible clear then see this






Preet Vadaliya

You have access to the ai2 source codes so you can make the appropriate adjustments to make it work well. I think it's you, I gave you an idea how to solve the problem with the slider on GitHub.

Yes you are right.

@Himanshu2107 can you please check this problem because your project is related to Canvas and Sprite.

I also request all @powerusers to please test this bug because probably this problem occurred in all visible components.

It is true. Label:

testtest

1 Like

Yes exactly.

Check your device density with this extension you can also understand this problem is occurs due to float to int conversation

We understand the problem and we know why it occurs. Rounding values. But is there a way around it, fix it?

What if the original width value was stored in a variable, and not overwritten after conversion? The calculated value would be used only for drawing, setting width and height. On the other hand, a block that returns width would return the original value, unmodified. Is it possible?

Yes, we can solve the problem using this approach.

Yes, it is possible.

The Designer Property value is in Pixels? Even if it is a different Unit (other than the Unit it Claims to be), that should not matter when comparing items of identical dimension in identical units.

If you apply a dimension of 403 to the Sprite, it should become 146 post equation. If a Canvas or another Sprite is also set to an identical 403, it should also become 146 post equation -unless a slightly different equation is being used?

If you set the canvas height and sprite height to numeric values, eg 399, then it will be ok. Both components will be set to 399, but will return 398. No problem in converting DP to PX. The problem is in converting PX to DP, i.e. in a block that returns height or width. If something has been rounded to an integer value, it is impossible to mathematically recover a floating point value identical to what it was before the conversion.

@preetvadaliya writes about discarding the rest. I don't know how it works in the code, but if the rest are actually dropped, maybe that's the problem? Maybe instead of discarding the remainder, it should be rounded to the nearest integer?

No, only name of the Designer property is Pixels.

Indeed that is true. So instead of using the Component Height Blocks, Rich should use integer math blocks for all dimensions to get consistency. For the purposes of CAM, only the dimensions will be accurate, not the drawing, which is unfortunate.

@ChrisWard @Patryk_F thank you for testing this bug I will try my best to solve this issue.

1 Like

Hi,
I have opened an issue on GitHub to track the progress.

Thank you for this extension!

Can you please explain what this means:

Tested on a Pixel 2XL (Android 11):

Density

XDpi = The exact physical pixels per inch of the screen in the X dimension.
YDpi = The exact physical pixels per inch of the screen in the Y dimension.

Yes, but why they are equal?