Introduction
Most of this behavior can be reproduced near the world border: /tp 29999950 29999950
Some of the strange rendering can also be seen closer to the center of the world but not in such an extreme way.
Reason for this bug
The 32-bit float simply run out of resolution/accuracy with the large coordinates. The solution is a bit of "ugly", but it got the work done, as I'm looking at perfectly fine wires at coordinates near X&Y of 17,000,000.
There are more unnecessary (and sort of harmful) (float)-casts in that same method, but they are for Y-coordinates, and since Y-coordinates are, for the time being, very limited, they do not show similar problems. (That whole class seems to be littered with those float-casts, many of which seem to be unnecessary and possibly causing similar issues for other blocks/visuals.)
comment by @unknown on MC-3718
Other bugs caused by this
Fix for fire's smoke
This time no source code as the changes cover almost the whole method. But its the very same fix, in BlockFire.randomDisplayTick(), change floats to doubles and remove casts to float when the variables are handling coordinates. This also includes sound generation coordinates.
comment by @unknown on MC-3718
Affected entities, blocks or particles
The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.
Falling blocks
The offset is probably caused by the method net.minecraft.client.renderer.entity.RenderFallingBlock.doRender(EntityFallingBlock, double, double, double, float, float)
. The texture being too large, shifted and rotated is caused by something else.
Particles
Apparently only affects particles created under certain circumstances
Landing particles, see MC-76810 created by @unknown
Particles created by the
/particle
commandTNT explosion particles
Green bone meal particles
barrier
particlesMCP 9.35 rc1 name
Method:net.minecraft.client.multiplayer.WorldClient.showBarrierParticles(int, int, int, int, Random, boolean, MutableBlockPos)
Rain and snow
Rain and snow renders as large white lines when you are at a very high y-coordinate. This does however only happen for large y, but not for x or z coordinates.
/teleport ~ 3000000 ~
Linked issues
is duplicated by
relates to
Attachments
Comments
We didn't want to reopen MC-3718 so we moved the still/newly affected stuff here.

Marcono1234: Just in case mods didn't already tell you this, please use the 'preview'-feature when trying to get the formatting right. Every single little committed/saved change generates a new email for those who are (still) watching the issue. Teh spam...
Also, all those tables of offsets are likely useless details; the reason is very likely still the old simple one: floating-point rounding, especially because of using 32-bit single-precision float instead of 64-bit double-precision.
However, listing which things are (still) affected and in which way they can be checked (if it is not trivial) should be useful.
I added several comments about fixes in the old MC-3718, but I'm not going to bother rechecking the possible current causes and/or adding the details to this issue. Its too much work for no effect; it has soon been 3 years and this issue is still kicking strong...

I am sorry, I did not know about the preview feature. When I did this I was also concerned about the spam :/
Also, all those tables of offsets are likely useless details; the reason is very likely still the old simple one: floating-point rounding, especially because of using 32-bit single-precision float instead of 64-bit double-precision.
If you know it better, then please add a comment. I am not familiar with the code and I only added the things known. The tables still might be usefull as they provide at least some information.
However, listing which things are (still) affected and in which way they can be checked (if it is not trivial) should be useful.
I guess I did exactly that. Most of the things described in the old report are fixed (if not all). For pistons for example an explanation would make no sense as it would look like this: "Place a piston, power it"...
And like I said if you have specific suggestions, please just write them in the comments and I will try to add them.
A video demonstrating the "fix" for this bug, which shows the laggy and not laggy rendering in comparison
https://www.youtube.com/watch?v=KGPwPC7u03w

More correctly, the fix in the video fixes another bug than the ones listed here, but the causes are the same: unnecessary/harmful float casts. (The original source code might not have explicit float casts, but e.g. implicit use of float-type, and the compiler creates the casts. Whatever, end result is the same.)
yeah the people in the video's comments just told me the same: it's another bug and also that the video's bug was already fixed (but in a later version than the one used in the video) so just ignore the video I posted it's only related in the aspect you just mentioned
that there are unneccessary float casts that should be removed (but might be caused by the compiler and are better visible in MCP translated minecraft code)
Included MC-50142, sorry for not staying with your formatting @unknown 🙂

@unknown you can directly write MC-50142
and it will become a link. That way it is also easier to see what this report is about because it gets a hover text as well.
@unknown that is kind of alright 🙂
So that's why Swekob's mentioned tickets aren't struck through when closed. @unknown: Please stop linking tickets your way, it's very confusing.

MC-50142 rather duplicates this report here now
@unknown & @unknown: I just realized that just before reading your comments! Thanks anyway 🙂
Confirmed for 15w45a.
Affects 15w47c
Since the teleport in hight became limited in 1.9.3, I assume the Rain and Snow part will not be fixed.

Affects 17w13b, at least for falling sand: https://bugs.mojang.com/browse/MC-115402

Since the teleport in hight became limited in 1.9.3, I assume the Rain and Snow part will not be fixed.
@@unknown you can still summon an entity at heigh y coordinates and then teleport yourself to it.

I can no longer reproduce this in 17w47a.
Sand blocks are stuck like that in 18w07c.
still not resolved.

Can confirm for the barrier block and TNT particles in 18w09a.

Can confirm for 18w10a.

Can confirm for 18w11a and 18w14a.

Can confirm for 18w15a.

Can confirm for 18w16a.

Can confirm for 18w19b.

Can confirm for 18w20c.

Still an issue in 1.13 PRE-2

Affects 18w47b

Affects 18w49a. Can I request ownership of this ticket?

Affects 18w50a

@@unknown, you are now the reporter.

I'm tempted to split this ticket up further, since there's multiple different issues caused by floating point casting. Willing to discuss this on the eigencraft discord.
I'd say, go ahead, better to have specific small tickets, than a huge one with everything lumped together.
With 19w39a, the issue with falling sand seems to have been fixed at least.

We don't want to have too many large tickets collecting multiple symptoms of what might be the same bug anymore. If there's a code analysis and that code analyis confirms that multiple symptums stem from the same bug, we can do a collection about all instances of the bug, sure. In this case, this seems to be about multiple different cases in which coordinates are not handled correctly by the client – such tickets, we have noticed, are not really helpful to the devs. This ticket has a code analysis, so it's not too bad. But if there's more instances of this bug appearing, things get chaotic rather quickly.
An extreme example with what can happen if we lump too many issues in one ticket can be seen in MC-9553 and MC-138550 for example. We rather have multiple tickets that are neatly cleaned up and linked, rather than one big ticket where everything gets thrown in.

I've split the ticket into MC-161888, MC-161968, MC-161969, MC-161970, MC-161972, MC-161974, MC-161975 and MC-161981, as well as the two existing tickets MC-125638 and MC-76810 that still affect 19w39a.
I'm not sure if the rain issue is still valid, since it's not possible to teleport up that high without using NBT editors or a mod. There's aso some other hard to test prefcision loss errors that I might make tickets for later. Since this is now (to my knowledge) completely split, can it be closed?

You can get arbitrarily high by setting Pos[1] of a dummy entity to a high value (for some reason this requires the "d" at the end) and then (in the same tick?) teleporting yourself to it.

Since I've split this ticket up, can it be resolved?
Done.
This ticket has been resolved as invalid as it contained multiple destinct issues. It has split up into separate tickets, most of which are linked as related to this ticket and/or MC-76810.
Literally a dupe of MC-3718. Heck, you even copied the summary.