Paper/src/main/java/net/minecraft/server/PlayerChunk.java

169 Zeilen
6.2 KiB
Java

package net.minecraft.server;
import java.util.ArrayList;
import java.util.List;
2012-12-20 05:03:52 +01:00
class PlayerChunk {
2012-07-29 09:33:13 +02:00
private final List b;
private final ChunkCoordIntPair location;
private short[] dirtyBlocks;
private int dirtyCount;
2012-07-29 09:33:13 +02:00
private int f;
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
private boolean loaded = false; // CraftBukkit
2012-12-20 05:03:52 +01:00
final PlayerChunkMap playerChunkMap;
2012-12-20 05:03:52 +01:00
public PlayerChunk(PlayerChunkMap playerchunkmap, int i, int j) {
this.playerChunkMap = playerchunkmap;
this.b = new ArrayList();
2012-03-01 11:49:23 +01:00
this.dirtyBlocks = new short[64];
this.dirtyCount = 0;
this.location = new ChunkCoordIntPair(i, j);
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
// CraftBukkit start
2012-12-20 05:03:52 +01:00
playerchunkmap.a().chunkProviderServer.getChunkAt(i, j, new Runnable() {
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
public void run() {
2012-12-20 05:03:52 +01:00
PlayerChunk.this.loaded = true;
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
}
});
2013-03-25 05:22:32 +01:00
// CraftBukkit end
}
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
public void a(final EntityPlayer entityplayer) { // CraftBukkit - added final to argument
if (this.b.contains(entityplayer)) {
2012-07-29 09:33:13 +02:00
throw new IllegalStateException("Failed to add player. " + entityplayer + " already is in chunk " + this.location.x + ", " + this.location.z);
} else {
this.b.add(entityplayer);
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
// CraftBukkit start
if (this.loaded) {
entityplayer.chunkCoordIntPairQueue.add(this.location);
} else {
// Abuse getChunkAt to add another callback
2012-12-20 05:03:52 +01:00
this.playerChunkMap.a().chunkProviderServer.getChunkAt(this.location.x, this.location.z, new Runnable() {
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
public void run() {
2012-12-20 05:03:52 +01:00
entityplayer.chunkCoordIntPairQueue.add(PlayerChunk.this.location);
Load chunks asynchronously for players. When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
2012-11-30 09:49:19 +01:00
}
});
}
// CraftBukkit end
}
}
public void b(EntityPlayer entityplayer) {
2011-05-31 15:55:45 +02:00
if (this.b.contains(entityplayer)) {
2012-12-20 05:03:52 +01:00
entityplayer.playerConnection.sendPacket(new Packet51MapChunk(PlayerChunkMap.a(this.playerChunkMap).getChunkAt(this.location.x, this.location.z), true, 0));
this.b.remove(entityplayer);
2012-07-29 09:33:13 +02:00
entityplayer.chunkCoordIntPairQueue.remove(this.location);
if (this.b.isEmpty()) {
long i = (long) this.location.x + 2147483647L | (long) this.location.z + 2147483647L << 32;
2012-12-20 05:03:52 +01:00
PlayerChunkMap.b(this.playerChunkMap).remove(i);
if (this.dirtyCount > 0) {
2012-12-20 05:03:52 +01:00
PlayerChunkMap.c(this.playerChunkMap).remove(this);
}
2012-12-20 05:03:52 +01:00
this.playerChunkMap.a().chunkProviderServer.queueUnload(this.location.x, this.location.z);
}
}
}
public void a(int i, int j, int k) {
if (this.dirtyCount == 0) {
2012-12-20 05:03:52 +01:00
PlayerChunkMap.c(this.playerChunkMap).add(this);
}
2012-07-29 09:33:13 +02:00
this.f |= 1 << (j >> 4);
2012-03-01 11:49:23 +01:00
if (this.dirtyCount < 64) {
short short1 = (short) (i << 12 | k << 8 | j);
for (int l = 0; l < this.dirtyCount; ++l) {
if (this.dirtyBlocks[l] == short1) {
return;
}
}
this.dirtyBlocks[this.dirtyCount++] = short1;
}
}
public void sendAll(Packet packet) {
2012-11-06 13:05:28 +01:00
for (int i = 0; i < this.b.size(); ++i) {
EntityPlayer entityplayer = (EntityPlayer) this.b.get(i);
2012-07-29 09:33:13 +02:00
if (!entityplayer.chunkCoordIntPairQueue.contains(this.location)) {
2012-12-20 05:03:52 +01:00
entityplayer.playerConnection.sendPacket(packet);
}
}
}
public void a() {
if (this.dirtyCount != 0) {
int i;
int j;
int k;
if (this.dirtyCount == 1) {
2012-07-29 09:33:13 +02:00
i = this.location.x * 16 + (this.dirtyBlocks[0] >> 12 & 15);
2012-03-01 11:49:23 +01:00
j = this.dirtyBlocks[0] & 255;
2012-07-29 09:33:13 +02:00
k = this.location.z * 16 + (this.dirtyBlocks[0] >> 8 & 15);
2012-12-20 05:03:52 +01:00
this.sendAll(new Packet53BlockChange(i, j, k, PlayerChunkMap.a(this.playerChunkMap)));
if (PlayerChunkMap.a(this.playerChunkMap).isTileEntity(i, j, k)) {
this.sendTileEntity(PlayerChunkMap.a(this.playerChunkMap).getTileEntity(i, j, k));
}
} else {
int l;
2012-03-01 11:49:23 +01:00
if (this.dirtyCount == 64) {
2012-07-29 09:33:13 +02:00
i = this.location.x * 16;
j = this.location.z * 16;
2012-12-20 05:03:52 +01:00
this.sendAll(new Packet51MapChunk(PlayerChunkMap.a(this.playerChunkMap).getChunkAt(this.location.x, this.location.z), (this.f == 0xFFFF), this.f)); // CraftBukkit - send everything (including biome) if all sections flagged
2012-03-01 11:49:23 +01:00
for (k = 0; k < 16; ++k) {
2012-07-29 09:33:13 +02:00
if ((this.f & 1 << k) != 0) {
2012-03-01 11:49:23 +01:00
l = k << 4;
2012-12-20 05:03:52 +01:00
List list = PlayerChunkMap.a(this.playerChunkMap).getTileEntities(i, l, j, i + 16, l + 16, j + 16);
2012-03-01 11:49:23 +01:00
2012-11-06 13:05:28 +01:00
for (int i1 = 0; i1 < list.size(); ++i1) {
this.sendTileEntity((TileEntity) list.get(i1));
2012-03-01 11:49:23 +01:00
}
}
}
} else {
2012-12-20 05:03:52 +01:00
this.sendAll(new Packet52MultiBlockChange(this.location.x, this.location.z, this.dirtyBlocks, this.dirtyCount, PlayerChunkMap.a(this.playerChunkMap)));
for (i = 0; i < this.dirtyCount; ++i) {
2012-07-29 09:33:13 +02:00
j = this.location.x * 16 + (this.dirtyBlocks[i] >> 12 & 15);
k = this.dirtyBlocks[i] & 255;
2012-07-29 09:33:13 +02:00
l = this.location.z * 16 + (this.dirtyBlocks[i] >> 8 & 15);
2012-12-20 05:03:52 +01:00
if (PlayerChunkMap.a(this.playerChunkMap).isTileEntity(j, k, l)) {
this.sendTileEntity(PlayerChunkMap.a(this.playerChunkMap).getTileEntity(j, k, l));
}
}
}
}
this.dirtyCount = 0;
2012-07-29 09:33:13 +02:00
this.f = 0;
}
}
private void sendTileEntity(TileEntity tileentity) {
if (tileentity != null) {
2012-11-06 13:05:28 +01:00
Packet packet = tileentity.getUpdatePacket();
if (packet != null) {
this.sendAll(packet);
}
}
}
2012-07-29 09:33:13 +02:00
2012-12-20 05:03:52 +01:00
static ChunkCoordIntPair a(PlayerChunk playerchunk) {
return playerchunk.location;
2012-07-29 09:33:13 +02:00
}
2012-12-20 05:03:52 +01:00
static List b(PlayerChunk playerchunk) {
return playerchunk.b;
2012-07-29 09:33:13 +02:00
}
}