user-ed7ab

Yes, the bug does still exist in this version.

> The tearing issues appears if I enter a map with VSync enabled but disabling and enabling it fixes the issue.

On this test disabling and enabling VSync has not fixed the issue but the tearing was more difficult to see (probably I have just not noticed it on the last test).

> The new process calls for moving stale (read: months with no update) to a status of "Awaiting Response" until something is updated.

Hm, I'm not sure what you are meaning.

> Please attach an updated forced crash report

In the attachments is the new log.

Even with all updated the issue still exists but I figured out something new: The tearing issues appears if I enter a map with VSync enabled but disabling and enabling it fixes the issue. But leaving and joining again a map will cause this issue again until I disable and enable VSync again.

Edit: By accident you have closed this ticket and it seems I can't reopen it.

This is what I have expected at most. But I'm not wondered about that Mojang is not able to fix these things.

Is there a special reason anisotropic filtering was removed?

I'm noticing a little difference:

> 1.3. Setting the frame limit to 50 will result in 50 FPS with no tearing.

I'm seeing tearing effects but they are hard to see (maybe they existed already in 1.7.4). Setting the frame limit to 40 FPS makes them easier to see. Currently I can't tets the part related to TripleBuffering as I'm noticing other issues (maybe a bug in the driver). But for now the issue is that setting the frame limit to a non-syncing value will break VSync.

It is still an issue as:

• The user doesn't expect to explicitly to logout. Normally he would think closing the launcher would be enough.

• The first login stores the information already on the disk which is a security issue.

> Why does Minecraft need a special process to catch crashes? I'm pretty sure OS X and probably Linux have APIs to handle that.

The runtime environment of Java/OpenJDK should be able to catch all crashes related to programming errors and signals (at least on Linux as I don't know how other operating systems are handling this) except SIGKILL. Only if the runtime environment receives a SIGKILL this is normally not possible anymore. But such a situation caused by a crash is very rare and normally less important for Minecraft.

In this case at least "Close launcher when game starts" should be renamed to "Hide launcher when game starts" to avoid confusion. But I would still prefer if the launcher would really close. If somebody wants to catch crashes he can set the option to "Keep the launcher open".

> The thing is that the process can be killed manually and the game runs just fine, so there doesn't seem to be a point in keeping the process alive.

The same happens on Linux if I'm terminating the launcher process manually. The process should just exit after Minecraft started which should solve the icon issue on OS X and the process issue on all operating systems.

I'm seeing this behavior too on version 1.3.9 (Linux 3.13 with OpenJDK 1.7.0_51). The option "Close launcher when game starts" is enabled but the launcher window does only hide and is still keeping his process open.

As long as #42310 is a duplicate version 1.7.4 is still affected.

> Where are you getting the FPS numbers from?

From the ingame menu (F3).

It is really unstructured to sort this out on another site where you need an extra account especially because feature requests would fit really good in here (but this doesn't really wonder me if I'm looking into the past of Mojang^^). At least this explains why I couldn't choose anything besides "Bug" as type.

I'm also able to reproduce this bug on Minecraft 1.7.4 on Linux.

> However, if you turn on MIP (all the way up) first, save the settings, and then turn Anisotropic filtering (all the way up) and save the settings again, the issue is not > present.

I have tested this and the workaround does at least not work on my system.

The keywords used were "Fullscreen minimize".

After making a look it seems that my volunteer theory is correct. Anyway - this problem is still a valid issue. Just think of a power loss of a server. The most hoster doesn't have control over such unexpected crashes and it will simply bork the player status of a world. Also fixing this shouldn't be really difficult.

Correct, the information isn't written to the disk because the process logically can't do this anymore. But my startpost already includes a potential solution for this.

Normally crashes are appearing unexpected so every running server could be affected at a time.