A brief (well, maybe not) explanation with ASCII graphics for the people still confused with the casting bar change:
Both now and after the patch, the ability to cast a new spell is determined
client side, but currently the knowledge about what you are actually casting is determined
server side. The latter is what is changing in 2.3.
Live, no stop casting
Server [---casting---] [---casting---
/ \ / \ / \
/ \ / \ / \
Client ......[---cast|*****] ......[---cast|**
A B C D E
The graph above represents current chain casting without the use of the /stopcasting command. At point A, we have the initial button press, which after some latency travels to the server and initiates the actual cast.
The server then sends a message back to your client telling the client you have begun casting; accordingly your client starts the cast bar at point B. You actually started casting the spell on the server one half of your ping ago by the time your cast bar starts.
Once the cast finishes on the server, it sends another message to your client which after some latency reaches your client at point D and terminates the casting bar. Now your client will let you begin casting another spell and the process repeats. Generally, this means without using stopcasting your spells gain one roundtrip time; in other words your ping is added to the cast time.
Live, stop casting
Server [---casting---] ! [---casting
/ \ / / \
/ \ / / \
Client ......[---cast|*! ......[---cast
A B C D E
In order to get around that added time, people use the notion of the /stopcasting command; from point C in the above diagrams, any command issued will reach the server
after the server finishes the current cast - points C through D are the parts of the cast bar colored red by Quartz and other latency-measuring addons.
Accordingly, a /stopcasting command is issued partway through this time at point D; instead of waiting to complete normally, the
client-side cast is canceled while the
server-side cast completes. The client therefore allows the next cast to begin immediately without waiting an additional one-way trip from the server.
Properly applied, the stopcasting method allows you to shave one-half your ping off of your cast time without using stop casting, in the best case.
2.3, no stop casting
Server [---casting---] [---casting
/ /
/ /
Client [---casting---] [---casting---
A B C
In 2.3, the proposed 'fix' to using stop-casting is to desynchronize the client and server cast bars. In other words, once you cast a spell, the
client will be in charge of determining when it ends, rather than the server (for purposes of letting you cast another spell). Effectively, this results in the ability to chain cast in the same manner as using stopcasting, without the added risk of canceling your current spell by attempting to cast again too soon.
This would return the /stopcasting command to its original purpose, for when you actually wanted to stop casting something to use a different ability.
And no, this shouldn't increase network traffic, as the client shouldn't be actually sending the cast command when you spam it before you're able to cast the next spell; it doesn't do that right now either, or the whole stopcasting thing wouldn't be necessary on live.