The new JSON protocol has 977 characters and old protocol has 666 characters. It looks like the new protocol transferred more information than old protocol. And it unnecessarily format integer to 123.0. I'm not sure if it is due to the upgrade on draw2d/GEF or simply because of JSON format. Is that possible to simplify the JSON format?
]]>Xihui Chen2012-05-30T18:56:52-00:00Re: New JSON protocol doubled the traffic on draw2d paintinghttps://www.eclipse.org/forums/index.php/mv/msg/357062/879459/#msg_879459
> The new JSON protocol has 977 characters and old protocol has 666

Okay, so a few notes:
a) This would not be doubled, its about 150% (double would be 200%).
b) Your examples do not do the same thing, the JS output uses less font
names and does no text measurement. If you take that into account,
its much nearer to parity.
c) If you also take the http-compression of the response into account,
its debatable which is longer.

Yes, the new protocol may be a bit longer in same cases for GC. But we
knowingly accepted that. The reason is that the new protocol is much
closer to the html5-canvas syntax, which gives as several advantages for
future development and maintenance.

Professional services for RAP and RCP?http://eclipsesource.com/services/rap/]]>Tim Buschtoens2012-05-31T09:05:44-00:00Re: New JSON protocol doubled the traffic on draw2d paintinghttps://www.eclipse.org/forums/index.php/mv/msg/357062/879622/#msg_879622
Thank you for explaining that! Yes, the example I posted here is 150%, but for complicated draw2D widgets as in attached screenshot, it is about 200%. Its traffic is around 650KB/S on RAP 1.4.1 and 1.3MB/S on RAP 1.5M7. I also attached the message details. With http compression, the text message can be compressed to 6:1, so the traffic could not be a big problem. If the new protocol is more efficient for client to parse, it may get a better performance overall. I didn't mean to criticize the new protocol. I know it has lots of advantages. I just hope it can be improved to have a shorter length. For example, removing all white spaces could save about 1/5 length.

We have always pointed out that a high performance Draw2D for RAP is
possible, but it requires a different implementation that bypasses the
SWT API and directly passes vector data to the client GC. This is not a
simple task, it will probably involve months of work.

The current GEF component in the RAP Incubator is not designed for this
ammount of data. If it works for you, you're lucky, but the problem with
your approach is not the protocol. It's the amount of GC operations
needed to draw these charts.

Professional services for RAP and RCP?http://eclipsesource.com/services/rap/]]>Ralf Sternberg2012-06-01T19:45:47-00:00Re: New JSON protocol doubled the traffic on draw2d paintinghttps://www.eclipse.org/forums/index.php/mv/msg/357062/881466/#msg_881466
Best regards,
Xihui]]>Xihui Chen2012-06-04T15:55:57-00:00