Zircle rendering at wrong position on Mobile browser

Question

Zircle rendering at wrong position on Mobile browser

opened this issue 5 years ago · comments

https://codepen.io/zircle/pen/ejXaNY
On Android chrome, four layer down, zircle starts dipping from center of the screen. Same example works perfectly on Web chrome. On web, the zircle dips but renders itself to the center immediately, which is not happening on Android browser. Tested on Android chrome.

Juan Martin · Answer 1 · Wed Oct 30 2019 18:49:48 GMT+0800 (China Standard Time)

Thank you for informing this issue. Could you change the zircle version on codepen to zircle@1.4.0-rc.1 or zircle@1.4.0-beta.3 and test again on android?

Deleted user · Answer 2 · Thu Oct 31 2019 02:17:58 GMT+0800 (China Standard Time)

Tested zircle@1.4.0-rc.1 and Zircle@1.4.0-beta.3

Result : Issue is persistent in Android Chrome and even web is affected.

Android Chrome

Level 1

Level 2

Level 3

Level 4

Level 5

Web

Level 1

Level 2

Level 3

Level 4

Level 5

Juan Martin · Answer 3 · Thu Oct 31 2019 06:39:38 GMT+0800 (China Standard Time)

Thanks for testing! The issue is a limitation of zircle that occurs when you zoom deeper. The problem is the scale transform property of the active view at the fourth of the fifth level has a lot of decimals that are not handled properly by the browsers. For this reason, the current maximum level of depth is 5. To solve that problem I'm drafting a solution to get rid off the limit of zoom navigation, but I haven't much time to work on it. El mié., 30 oct. 2019 a las 15:18, KGB (<notifications@github.com>) escribió:

…

Deleted user · Answer 4 · Thu Oct 31 2019 16:42:10 GMT+0800 (China Standard Time)

When I did console log of X,Y in position.js for web and mobile

X = ((store.actions.getComponentWidth(parentSize) / 2) * distance / 100) * Math.cos(angle * (Math.PI / 180))
Y = ((store.actions.getComponentWidth(parentSize) / 2) * distance / 100) * Math.sin(angle * (Math.PI / 180))
console.log(X,Y)

For the same angle the X,Y are calculated to same decimal precision but they differ in deeper levels. Strange.

In my observation with zircle@stable, on the web the zircle dips down at deeper level but quickly comes back to the center.

Which makes me wonder, can the position be manually centered using css. Any suggestions?

Juan Martin · Answer 5 · Thu Oct 31 2019 17:15:30 GMT+0800 (China Standard Time)

Maybe this can be done by adding a css style with "!important" trying to override the transform property on the current view. However, I believe that to solve this issue it is better to rewrite the position "engine".

Deleted user · Answer 6 · Thu Oct 31 2019 18:46:43 GMT+0800 (China Standard Time)

Thanks for the hint. Efforts to manually reset transform failed. When i dug deeper, i found this great article on browsers rounding up decimal points
Turns out that round up of decimal places in transform: translate3d is the culprit and position "engine" isn't at fault.

Zircle's strongest feature is zoom and out which asthetically depicts hierarchy. If zoom-in and out is just treated as animation and each z-view is rendered with absolute positioning, there's wont be a need to dilute the coordinate system [Background will be lost]. But it's better than enforcing levels on the framework.

Framework's calculation are correct. You may close this thread. Thanks.

Juan Martin · Answer 7 · Thu Oct 31 2019 19:32:09 GMT+0800 (China Standard Time)

I really appreciate your feedback and interest on zircle. I aware of this limitations and for this reason I thought in another approach: Nowadays zircle perfoms true zoom navigation, but as you know the decimal points are not well handled by browser. At deeper scales the things behave weirdly. So, the objective of the new approach is to ensure the the new view is rendered always at scale factor 1. But starting at the same scale of the previous clicked element. This way you can make zoom indefinitely with out compromise performance and hierarchical experience. The previous views will increase the scale factor accordingly and as result the ux will remain intact Also, I will split the project in two. One for the circular shapes and the other for the zoom engine. This way the zoom engine will be used with any element that has a “is-zoomable” class. I hope I can deliver soon a working concept. What do you think?

…

On Thu, 31 Oct 2019 at 07:46 KGB ***@***.***> wrote: Thanks for the hint. Efforts to manually reset transform failed. When i dug deeper, i found this great article on browsers rounding up decimal points <https://cruft.io/posts/percentage-calculations-in-ie/> Turns out that round up of decimal places in transform: translate3d is the culprit and position "engine" isn't at fault. Zircle's strongest feature is zoom and out which aesthetically depicts hierarchy. If zoom-in and out is just treated as animation and each z-view is rendered with absolute positioning, there's wont be a need to dilute the coordinate system [Background will be lost]. But it's better than enforcing levels on the framework. Framework's calculation are correct. You may close this thread. Thanks. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33?email_source=notifications&email_token=ACYFYDOPOE3S7E3PD55OQXTQRKZRJA5CNFSM4JGV3352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXJE3A#issuecomment-548311660>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYFYDPGEQ2B5EBSIWKTNGDQRKZRJANCNFSM4JGV335Q> .

Deleted user · Answer 8 · Thu Oct 31 2019 21:18:47 GMT+0800 (China Standard Time)

Yes, sounds great, as long as transformation aren't in decimal coordinates the problem is solved. I think your new approach is absolutely correct. If the canvas made scaleable, zoom-in is practically infinite. Performance optimisation may be required, since all parents will need to be transformed not just scaled.

Juan Martin · Answer 9 · Thu Oct 31 2019 22:16:16 GMT+0800 (China Standard Time)

That’s absolutely right! I think writing this solution, the project will be more stable and less experimental. In this sense, separating the zoom “engine” from the circle shapes will result in more maintaining and flexible project.

…

On Thu, 31 Oct 2019 at 10:18 KGB ***@***.***> wrote: Yes, sounds great, as long as transformation aren't in decimal coordinates the problem is solved. *I think your new approach is absolutely correct*. If the canvas made scaleable, zoom-in is practically infinite. Performance optimisation may be required, since all parents will need to be transformed not just scaled. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33?email_source=notifications&email_token=ACYFYDIIX2XU7ZHBFCUKVY3QRLLLRA5CNFSM4JGV3352YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXXOYI#issuecomment-548370273>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYFYDOAIGMX3CMU7IOAPXLQRLLLRANCNFSM4JGV335Q> .