当变换改变1px时元素向上100％ [英] element upward 100% when transform changed by 1px

问题描述

我在我的项目中使用css 3d transforms。我试图对其他几个元素的包含元素应用新的变换。我也试图对其子元素之一使用getBoundingClientRect。该容器中还有其他元素。当容器具有 transform css属性的此值时：

  translateZ （1026像素）rotateX（-90deg）rotateY（180deg）translateZ（439.001px）
  

c $ c> element.getBoundingClientRect（）。top 根据chrome的开发者工具，特定的子元素是 77.953109741210944 code> elements 选项卡将`transform属性更改为：

  ）rotateX（-90deg）rotateY（180deg）translateZ（439.001px）
  

c> element.getBoundingClientRect（）。top 是： -75048.6484375 什么可能会导致这种情况？我不发布任何代码，因为即使当我通过控制台修改值发生。当我做第一个 translateZ 像1000px，它仍然是大约77.即使是在0，边界rect的顶部约50-100某处。但是当它超过1026px时，这个元素似乎跳到了-80000左右。然而，视觉上，元素看起来像它应该，而不是跳跃随机在1027px。有人可能会说可能导致这种情况吗？

如果是浏览器错误或某事，我使用chrome 32.0.1687.2 dev-m Aura

编辑：

这里是一个jsfiddle链接：

浏览数字，您将得到以下观察结果：

1. 当 translateZ = perspective - 150px 时，边界框异常小且位置错误




2. 当 perspective - 150px< translateZ<透视+ 150像素，边框位于其应该位于的对面，尺寸异常大。




3. tranlateZ = perspective + 150px ，边界框再次异常小，位置更高1）






5. 150像素是广场宽度/高度的一半

   $ b

6. 当 tranlateZ>




为什么？<透明度+ 150像素 / p>

• 如果1）其中一个边缘正好与相机/透视所在的平面相交。


• 在情况2）正方形与相机平面相交


• 在情况3）情况1）中与边缘相对的边缘现在与相机/透视平面相交。

b b 3D坐标到屏幕上2D坐标没有考虑到两个角落在摄像机的前方，而另外两个角落在后面，因此产生错误的投影，因此造成错误的大小。




这是我的意思是它不明白3D。这是模糊的，因为它可以是我实现，对不起。当所有的形状都通过相机平面，它再次工作。





Firefox和Chrome都有这个问题，但有不同的表示，数字。可能因为使用了不同的投影矩阵。所以我不想弄清楚究竟发生了什么问题。向他们发出错误报告：）





实际上，你可能需要解决它。




I am using css 3d transforms in my project. I am trying to apply a new transform on the containing element of several other elements. I am also trying to use getBoundingClientRect on one of its child elements. That container also has other elements in it. When the container has this value for the transform css property:

translateZ(1026px) rotateX(-90deg) rotateY(180deg) translateZ(439.001px)

here's what element.getBoundingClientRect().top for that certain child element is: 77.953109741210944 according to chrome's developer tools but when I use the elements tab to change the `transform property to this:

translateZ(1027px) rotateX(-90deg) rotateY(180deg) translateZ(439.001px)

here's what element.getBoundingClientRect().top is: -75048.6484375 what would possibly cause this? I'm not posting any code because this occurs even when I modify the values through the console. And when I make the first translateZ something like 1000px, it is still about 77. Even when it is at 0 the top of the bounding rect is about 50-100 somewhere. But when it goes beyond 1026px, the elment seems to jump to top -80000 or so. Visually, however, the element look like it should and doesn't "jump" randomly at 1027px. Can somebody say a situation that might cause this?

in case it is a browser bug or something, I'm using chrome 32.0.1687.2 dev-m Aura

EDIT:

here is a jsfiddle link:

http://jsfiddle.net/a6KxQ/2/

It'll generate a table of all translateZ values and the resulting elt.getBoundingClientRect().top values. The code's messy, but in the outputted table, if you look over it carefully, you'll find that, at some point, the top value will randomly jump far, far down. And then it'll quickly recover to come back to it's previous value. Weird.

The fiddle might take a long time to load.

解决方案

As you suspected, It has to do with the perspective of the viewpoint. By increasing of the value for the 1st translateZ, you are bringing the rectangle closer to you. Eventually it is so close, it has passed the point of the camera. From that point on, the shape, un-rotated, stood behind your eyes.

Then you did a rotateX(-90deg). what happens there is the rectangle fell down forwards (towards the positive Z direction, but behind the camera.). Now, since the tunnel of the view is of a trapezoid shape, hence you get what we see in this screenshot:

With the rectangle behind the camera, as the it rotates, part of it is pivoted back into view.

So the getBoundingClientRect() is actually giving you the bottom of the shape's bound! Now that the shape is flipped, and it doesn't understand 3D.

I hope that made sense to you. I want to get to you first :) Ask me before down-voting, I can explain in more details.

so, it is by design. You probably want to restrict the translateZ value to be smaller than perspective.

EDIT:

sorry I have been busy. I meant to give a more detailed response. Thanks for whoever gave me the bounty.

A updated demo

Play around the numbers, you will make the following observations:

1. when translateZ = perspective - 150px, the bounding box is abnormally small and in wrong position

2. when perspective - 150px < translateZ < perspective + 150px, the bounding box is on the opposite side of where it should be, and the size is abnormally large

3. when tranlateZ = perspective + 150px, the bounding box is abnormally small again and higher in position in case 1)

4. the above is not affected by perspective-origin

5. 150px is half of the width/height of the square

6. when tranlateZ > perspective + 150px, the bounding box is normal again!

Why is that?

• in case 1) one of the edges just intersects with the plane that the camera/perspective is located.
• in case 2) the square intersects with the camera plane
• in case 3) the edge opposite to the edge in case 1) now intersects with camera/perspective plane.
• in case 6) all of the square has passed the camera plane

The projection algorithm used to convert 3D coordinates to on screen 2D coodinates does not take into account of the fact that two corners are infront of the camera, and two other corners are behind, hence creating a wrong projection, and hence wrong size.

That was what I meant by "it doesn't understand 3D". That was vague as it can be I realize, Sorry. When all the shape is passed the camera plane, it works again.

Firefox, and Chrome both have this problem, but have different representations, numerically. Probably because different projections matrix are used. So I don't want to figure out what exactly went wrong. Fire a bug report to them :)

Realistically though, you might need to work around it.

这篇关于当变换改变1px时元素向上100％的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！