Is it possible to enable GZIP compression for the websocket?

[dmm9]

I was testing some diagram with a large EMF model. The displayed model consists of 3000+ top-level nodes (i.e. 3000 GNodes direct children of the root), with their corresponding sub-elements (compartments, nodes, labels) and GEdges. When analyzing the network traffic in the browser, it seems the JSON packet for the model is about 7-8 MB size.

The network transfer is one factor delaying the display of the model. I was wondering if there is any option to enable gzip compression on the websocket of the glsp server. A quick search in google points to a compression rate of ~95% for JSON with gzip.

[tortmayr]

H @dmm9,
we have extracted this request into an issue (#1237).
We have to look into it but I think in general it should be possible to configure jetty and enable GZIP compression.

[dmm9]

Thanks for the info. Regardless of that, is it possible to show a message until the first render has finished? (re-renders once the diagram is dispayed should not open a message again. Or yes if desired?)

My sample model takes about 5 seconds to get rendered when the server is in localhost. Currently, there is one message displayed while (EMF) model loading, but in my case I preload the model beforehand, so that message dissapears immediately. And for some seconds (Gmodel computation, network transfer and render) the user is left with a blank screen and possibly wondering whether something went wrong. It would be great to have a message or a loading spinner while all this happens.

PS: following this topic, I am analyzing the network traffic. I will post some results soon.

[tortmayr]

Thanks for the info. Regardless of that, is it possible to show a message until the first render has finished? (re-renders once the diagram is dispayed should not open a message again. Or yes if desired?)

That certainly is possible. I guess the best approach would be to extend/customize the ModelSubmissionHandler
and start a progress notification in the submitInitialModel method. You could then override the createSetModelAction method to end the progress reporting.

PS: following this topic, I am analyzing the network traffic. I will post some results soon.

For your particular use case with really large EMF models it might also be worth to investigate how long the translation to the GModel takes. Fully iterating through the entire EMF model to recreate the GModel on every update might also be the bottleneck here.

[dmm9]

That certainly is possible. I guess the best approach would be to extend/customize the ModelSubmissionHandler
and start a progress notification in the submitInitialModel method. You could then override the createSetModelAction method to end the progress reporting.

Thanks a lot. I will explore the ModelSubmissionHandler.

For your particular use case with really large EMF models it might also be worth to investigate how long the translation to the GModel takes. Fully iterating through the entire EMF model to recreate the GModel on every update might also be the bottleneck here.

Yes, that is also interesting. In this particular case it takes ~2 seconds to generate de GModel. Not a big deal for the first render, but certainly critical if the model is updated frequently. I have posted my detailed network analysis results in #1249. You can get there a picture of what is taking how much time when it comes to rendering a diagram, and how relevant each factor is for big diagrams vs small diagrams.

I will mark this discussion as solved, as the issue #1237 is a better place to check on the progress about the compression topic. Thanks!