A ClientsideMap is considered "dirty" after you've written to it's graphics buffer. Dirty maps will be "cleaned" after they have been sent to a player. Only MapScreens are utilising this optimization technique at the moment. Depending on which DirtyHandlingPolicy enum constant you specified when updating a MapScreen, only dirty maps will be sent to players.

Let's say you are running a task every second that updates (MapScreen#update()) a certain MapScreen. You are calling the update method with the DirtyHandlingPolicy.SEND_DIRTY_ONLY enum constant, meaning that only dirty maps will be sent to the player(s).

Every time a player joins the server, you increment a counter and draw the counter onto the graphics buffer of the MapScreen. Now the next time the task runs the update method after a player has joined your server, your modifications will be sent to the player(s), because the underlying ClientsideMaps are considered "dirty".

That's a neat little optimization, isn't it?

There is one problem with this optimization: It won't optimize much in most cases because in order to draw new things, you first need to erase the old ones. If you don't clear¹ the graphics buffer before drawing, your new drawings will mix with the old ones, which oftentimes results in an undesired result - and clearing¹ the graphics buffer will mark it as dirty.

However, there is a solution for this at the expense of more memory usage - I lovingly call it the Advanced Content Change Algorithm. ^{_{I'm sorry, this was the best name I could come up with}}

¹ clearing the graphics buffer: The only way to clear the graphics buffer at the moment is by completely overwriting it with a certain color. There is no dedicated clear method at the moment.