FaRo1

Here is an article on a way to potentially fix this:

It describes a method that some painters use to create high FOVs, up to almost 180° (so exactly what Minecraft needs), while preserving a very natural, not distorted-seeming look. This has also been implemented in software, the code of that is not attached, but mathematical formulas are provided. I don’t know if it has been tried in a first-person game before, but should be worth a try at least.

I am deleting the world I linked in 2020, the link is broken anyway. If someone still wants it, just ask me, I should be able to restore it from a backup then.

I would be surprised if the first idea helped performance. If shaders break with tile entities, that is a mod bug.
But the second idea might also help with dragon heads, assuming that block models can grow outside the block grid, which I am unsure about, since signs, banners and lecterns have tile entities anyway, fence models are not visually higher and stuff like beds and doors is split into two blocks.

The video shows that inventory changes do not cause the regular old block updates, but many things already do not rely on those anymore. NeunEinser tried it and it seemed to work, so I would consider this report proven valid.

Plenty of entity actions update blocks, for example pressure plates. No constant checks are needed for that.

Very disappointing solution. This is an important bug, because it makes the entire website unusable for many people very often.

But you've never been active on this report before…

Reply from @unknown:
Please limit your comments to new information about the bug. This comment does not add anything to the report. Your concern may be valid, but this is at the discretion of the moderators. Delete this comment after reading.

Also affects some system messages in e.g. Japanese. Minecraft's confusion in "FaRo3???????????" may look funny a few times, but in the long term, it's annoying.

@unknown What about this is incomplete? Which question needs to be answered to reopen this?

Still happens sometimes in 23w33a with spiders.

The comments here seem like it got a lot worse in some version, so probably the distance of the search is not the only problem. But in case this cannot be fixed in a good way (seems like a computationally hard problem to me), here's an idea for an almost-fix:
While the current set of datapacks would cause such a map to be created, an earlier action (ship or ruin gets generated, villager takes job) could start a new thread that searches for the treasure. The resulting map could be added to a new item tag of the chest or villager that normally does nothing in regular gameplay, but once the chest is opened or the villager is unlocked far enough, the item gets moved into the slot/trade. That way, there's no lag and no timeout.

The problem then still exists if a datapack gets enabled, disabled or reloaded that changes the loot table, but that should almost never happen in regular Survival gameplay, meaning that this issue would affect way less players and way more rarely.
I'm not sure whether removing the treasure chest changes anything about the map (MC-108082 seems to suggest that it doesn't), if that's the case, then that's an edge case that my idea does not cover. Maybe someone else has an idea how to solve that. Maybe a server-wide cache for treasures, similar to portals, regular maps and villager POIs?
The idea works for things that can have NBT, but not for /loot or if a custom datapack adds it to fishing, cat/villager gifts, bartering or advancement rewards. Those would then still be laggy, but I've personally never seen this, except maybe in a loot table randomiser (in which people usually don't even bother with any of these things, because breaking blocks already gives them almost everything).

Yes, that's it. The duplicate report linked here has a video attached. Maybe a better wording would be "rendering of connected faces of transparent blocks of the same type".

This bug report was made after (and despite) a conversation with Slicedlime in which he already said that this is invalid. Please close.

duplicate of MC-256476

Interesting theory! But sadly it doesn't work. I just connected via AnyDesk, locked the local input and it still kept spinning around way too much and randomly looking up and down, like before. I think the more likely explanation is that when you move the cursor a bit to the right, it properly moves the in-game cursor to the right, but then resets the mouse. When you then move a bit more to the right, it moves the cursor the previous distance plus the new distance to the right, resulting in a much bigger motion and then Minecraft resets the cursor again. Summing up all previous vectors can lead to strange results like moving the cursor up and actually having the view move down, just because you moved more down than up on average so far.
This could be blamed on the remote control software, but it happens even with relative mouse movements like with xdotool.
Edit: I just tried "direct mouse mode" and it seems to confirm this. When I hold my finger very close to the crosshair, I can kind of control the game like with a virtual motion stick, just an extremely sensitive one and only while moving the finger.
BTW, if anyone intends to use remote-control to play Minecraft Java edition on the phone, I can recommend "PojavLauncher" instead, it actually runs the game on the phone instead of such workarounds. Of course that requires a fast phone, but mine can easily reach 60FPS on minimum graphics settings. The controls are even good enough that I used it once to deliver items to a faraway location, but it's not as good as playing on a computer, of course.

Just being hard doesn't mean that it won't be done. And it surely didn't make it WAI. You could maybe interpret WF into it, but there's already a Mojang priority on this, so it was triaged and not closed then, so it should stay open.

Now that you have an account, please only use it if you actually have new and useful information. Every comment here sends out 203 mails. And yes, Mojira has a bunch of big issues on its own, we know. If you want to discuss further, please go to reddit.com/r/mojira or the Discord group linked somewhere there.

@unknown Could you please not go through tons of tickets, making either obvious/redundant (MC-201, MC-1531, MC-3266, MC-1673, …) or incorrect (MC-180, MC-212, MC-2157, MC-2112, MC-2791, MC-1297, …) statements? I got lots of mails from your comments over night, followed by a bunch of mails of people correcting you. Please only contribute if you actually have new and relevant information, not baseless speculation. Also, if you want go through all currently open bugs, prepare some meals first, because you'll need a really long time for 8375 reports…

I looked up "overloaded comparators encoded storages" and the only useful result was this: https://www.youtube.com/watch?v=R5VuagERLWA
It uses a bug to stack books and mentions using this in a storage system somehow, but wouldn't you only get up to power 15 unless you intentionally cause buggy stacks?

This issue is suddenly a lot more important, because you can be banned for not following the "community standards", which I have never heard of before the latest MCJava changelog and which are inaccessible due to this "access denied". I can't follow rules that I'm not told about.