RoboMWM · April 2, 2018 03:13
diff --git a/gistfile1.txt b/gistfile1.txt
 [00:59:34] +Mana: [Empire92] Aikar, FAWE dispatching the changes on the main thread. It also loads chunks on the main thread. It's the preprocessing that's async, so the main thread will cache the chunk data for the async thread to access.
 [01:01:20] +Mana: [Empire92] So the async thread will calculate what block changes need to be done for e.g. generating a sphere
 [01:03:22] +Mana: [Empire92] Relighting is done async though (can be disabled), and some things on the main thread are done in parallel (not async, and only if enabled)

 [10:07:09] @Empire92: parallel / using nms / removing a lot of WorldEdit overhead
 [10:07:43] RoboMWM: nms for what again?
 [10:07:49] @Empire92: block changes
 [10:07:56] RoboMWM: I thought that was for thread safety for block placing async
 [10:08:15] @Empire92: no, it's to bypass the bukkit api, which is extremely slow for doing block changes

 [10:09:19] @Empire92: It's also implemented completely differently to AWE
 [10:09:47] RoboMWM: any major highlights regarding that differentiation?
 [10:13:39] @Empire92: RoboMWM, So AWE "asyncs" specific methods in the EditSession, and creates a new entry in the dispatcher for each block change.
 [10:13:54] @Empire92: The changes are grouped into "jobs" which are per player
 [10:14:39] @Empire92: FAWE executed the processing on the same thread the EditSession method was called from
 [10:16:02] @Empire92: And the queue is fairly different, it organizes by chunks which are dispatched, rather than individual blocks as you already know
 [10:17:03] @Empire92: And AWE has a design flaw where the EditSession can't get blocks in unloaded chunks (it will try, and switch to the dispatcher when it fails to load chunks async)
 [10:17:38] RoboMWM: ah, Aikar complained about it loading chunks async
 [10:17:44] RoboMWM: iirc
 [10:18:02] @Empire92: Well, it doesn't actually load it async because the AsyncCatcher throws an exception which stops it

 [10:19:16] RoboMWM: so as for editsession, AWE splits that up to be processed later, whereas FAWE starts working on it immediately?
 [10:19:38] @Empire92: So you'll see it here as an example: https://github.com/SBPrime/AsyncWorldEdit/blob/master/AsyncWorldEdit/src/org/primesoft/asyncworldedit/worldedit/AsyncEditSession.java#L207-L221
 [10:20:00] @Empire92: He had to modify the method to call the task asyncronously
 [10:20:36] @Empire92: Wheras since I've solved the issue of getting blocks from unloaded chunks from an async thread I can just call any method async without issue
 [10:20:48] @Empire92: don't need to recode each method to be async
 [10:21:46] RoboMWM: ah ok, working on same async thread vs. new async thread
 [10:22:08] @Empire92: It also means that AWE isn't async for everything (he may have made progress with the premium version, idk) but last I checked brushes weren't async
 [10:22:29] @Empire92: and some other commands
	[00:59:34] +Mana: [Empire92] Aikar, FAWE dispatching the changes on the main thread. It also loads chunks on the main thread. It's the preprocessing that's async, so the main thread will cache the chunk data for the async thread to access.
	[01:01:20] +Mana: [Empire92] So the async thread will calculate what block changes need to be done for e.g. generating a sphere
	[01:03:22] +Mana: [Empire92] Relighting is done async though (can be disabled), and some things on the main thread are done in parallel (not async, and only if enabled)

	[10:07:09] @Empire92: parallel / using nms / removing a lot of WorldEdit overhead
	[10:07:43] RoboMWM: nms for what again?
	[10:07:49] @Empire92: block changes
	[10:07:56] RoboMWM: I thought that was for thread safety for block placing async
	[10:08:15] @Empire92: no, it's to bypass the bukkit api, which is extremely slow for doing block changes

	[10:09:19] @Empire92: It's also implemented completely differently to AWE
	[10:09:47] RoboMWM: any major highlights regarding that differentiation?
	[10:13:39] @Empire92: RoboMWM, So AWE "asyncs" specific methods in the EditSession, and creates a new entry in the dispatcher for each block change.
	[10:13:54] @Empire92: The changes are grouped into "jobs" which are per player
	[10:14:39] @Empire92: FAWE executed the processing on the same thread the EditSession method was called from
	[10:16:02] @Empire92: And the queue is fairly different, it organizes by chunks which are dispatched, rather than individual blocks as you already know
	[10:17:03] @Empire92: And AWE has a design flaw where the EditSession can't get blocks in unloaded chunks (it will try, and switch to the dispatcher when it fails to load chunks async)
	[10:17:38] RoboMWM: ah, Aikar complained about it loading chunks async
	[10:17:44] RoboMWM: iirc
	[10:18:02] @Empire92: Well, it doesn't actually load it async because the AsyncCatcher throws an exception which stops it

	[10:19:16] RoboMWM: so as for editsession, AWE splits that up to be processed later, whereas FAWE starts working on it immediately?
	[10:19:38] @Empire92: So you'll see it here as an example: https://github.com/SBPrime/AsyncWorldEdit/blob/master/AsyncWorldEdit/src/org/primesoft/asyncworldedit/worldedit/AsyncEditSession.java#L207-L221
	[10:20:00] @Empire92: He had to modify the method to call the task asyncronously
	[10:20:36] @Empire92: Wheras since I've solved the issue of getting blocks from unloaded chunks from an async thread I can just call any method async without issue
	[10:20:48] @Empire92: don't need to recode each method to be async
	[10:21:46] RoboMWM: ah ok, working on same async thread vs. new async thread
	[10:22:08] @Empire92: It also means that AWE isn't async for everything (he may have made progress with the premium version, idk) but last I checked brushes weren't async
	[10:22:29] @Empire92: and some other commands
No results found