Marcel Maryniak

Using Xfce with Xorg on Linux Mint (Java 8) I do not experience this issue. Could it be that you use some sort of window decorator that does this?

It also seems fixed for MP in 15w42a as well 🙂

This should be a feature-request but not a bug report imo.

I could not reproduce this bug with the first command (setting the painting to invulnerable).

With the second command (changing the motive of the painting) the bug was reproducable BUT ONLY when the size of the original motive and the new target motive are different! For example in the screenshot above the Motive 'SkullAndRoses' can be seen, wich is a 2x2 block motive. When you try to set the Motive to 'Kebab' - wich is a 1x1 block motive - using the given command, the painting will turn invisible. A relog / re-entering the chunks will update the painting, turn it visible again and display the Motive specified in the command. The size of the painting will be adjusted accordingly.

If both original and target motive size are identical, the painting will not turn invisible. After setting a new motive it will, however, still display the original motive until the player relogs / re-enters the chunks.

==> The painting doesn't ever truly get turned invisible. Clients, however, are not immediately able to see changes made to a painting's entitydata (in regards to its motive, primarily) using commands, and the client will fail to render the painting completely, if the size of painting changes abruptly due to a new motive - until the client relogs / re-enters the chunks.

I hope this clarifies what the issue actually is.

All tests were done using MC version 'release 1.8.7'

I just tested this on release 1.8.7 and it is still an issue.

The same happens to me occasionally, not sure what causes it though.

Thank you very much, keep on the good work! 🙂

Still, its neither 'resolved' nor 'working as intended. If this is a duplicate, then at least reopen the original one.
As long as a Dev can find the issue (while the problem still exists) I'm happy with it. Right now the original one has a misleading title and description and thus is closed and marked as working as intended. Something that is working as intended doesnt need to be reviewed by devs and thus will not be found / fixed. My issue is a duplicate and thus is closed as well. Thus everything posted regarding this problem will be ignored by all Devs by default.
I hope we can agree on that if the problem I have mentioned here exists in the game currently, then either the original one with misleading dscription (at the very least) has to be reopened, or they have to be seen as different issues.

If we dont agree on that, it seems rather pointless to post in this bugtracker at all regarding this problem, because it wont be found by devs anyways.

This is not a duplicate of MC-40319, while the ppl in the comments are talking about this, 40319 was about a different issue in the firt place.
Furthermore the problem I am taking about here is neither 'resolved' nor 'working as intended'.

Please don't be mad at us, Mog 😞

It's just that after finally figuring out the cause of the issue, we tried to get Mojangs attention to it, since we were sure that it a) is the root cause of the problem and b) could be the main cause for at least 100 other bug reports where ppl complain about serious lag and/or high ram/cpu usage and - most importantly - Read Timeouts (wich ppl still falsely blame netty for). Seeing that Mindcrack has the same lag-spike issues, I even tried to contact some of the Mindcrackers, since they seem to have a more direct link to Mojang, but as a single person that task seems even more difficult than contacting one of the Mojangsters directly...

So after trying to get attention to this report for weeks and beeing sure that it is a severe, universial problem, still seeing it as 'unconfirmed' is a frustrating feeling...

Though, nobody can blame you for that either, after all, reaching Mojang and having an influence on the development on Minecraft (in certain borders) is possible and happening all the time. I think this is something that makes Minecraft very unique.
It's just that in cases like this where there are hundreds of bug reports showing the effects but only one or two actually showing the cause of the problem (or at least giving a very good hint on where to look) the ods are ppl upvote the reports they find first - wich are the ones showing the effects of the bug and so you can easily feel left alone...

So please don't take it personally, we love Minecraft and we love Mojang, if it wasn't that way we wouldn't even commit to this bugtracker 🙂

About deleting the data folder fixing the problem:
https://mojang.atlassian.net/browse/MC-33086
Saving structure data seems to take way too long on bigger maps for whatever reason, causing lag spikes.

Also, the block placing sounds for glass and redstone-lamps are also placed under "Friendly Creatures" where they shoud belong to Block sounds.

To the Issues regarding Read Timeouts of multiple Clients on 1.7.2 servers:

We were able to fix this issue by using
-XX:+UseG1GC
instead of
-XX:MaxGCPauseMillis=200

Seems like with standard configuration the garbage-collector was taking 2seconds or more at a time to free space, causing Clients to time out of course. Hope this helps 🙂