projector-client
                                
                                 projector-client copied to clipboard
                                
                                    projector-client copied to clipboard
                            
                            
                            
                        Perf optimization
The current web client is sub-optimal, it consuming lots of memory and causing GC a lot. I did some dirty hacks to improving the client's performance. Now, it can run smoothly on a 4K display. The hack is not well-designed. So, take what ever you need, just make sure that the web client runs more smoothly.
Hi @wpc009! Thank you for the great amount of work!
Could you share some details how you've found the places to optimize? Also, comparisons of performance before and after will be helpful.
We can check it ourselves but a bit later.
Finally, I think if something is compiled by Kotlin/JS inefficiently, it should be reported to https://youtrack.jetbrains.com/issues/KT and comments near hack in code should be left.
It true that a huge part of performance issue comes from the compiled JS code(It could be more efficient in pure JS code.). Lots of "isType" checks and "toTypedArray" conversion. Also, the int to string color conversion in fillStyle cause a lot of GC overhead. I appreciate the great work you have done, and really need this "Projector" solution in real works. By the way, I'm using the "Dev Tools -> Performance" panel to do the profiling, trying to reduce the render task costs.
Test scenario: Open java source code( around 500 lines), scroll up and down a little, and then scroll up to the beginning.
The Current head of Master build
 The yellow box are all "GC" overhead.
The yellow box are all "GC" overhead.
 These parts can be eliminate by using some pure javascript code and some color string cache to replace the code compiled from Kotlin.
These parts can be eliminate by using some pure javascript code and some color string cache to replace the code compiled from Kotlin.
PR

The optimized version use less time rendering the open stage. Also, the master branch build feels laggy.
profile details. These are the profile data, you can load them into Dev Tools.
I've looked a bit. There are many changes. Do you think we need them all? I just wonder maybe there are only a couple places that can be optimized a lot, and others a just minor enhancements.
I don't want to take all the changes because many make the code less readable.
I made some more optimization on the rendering logic.
- The origin code did clipon the first, and must reset all the canvas states at the end ofapplyClip. I re-arrange theclipoperation, make it possible to reusing previous canvas state.
- The measureTextduringfillTextcan be avoided, by caching the rescale ratio for each font size.
Thank you for going on 😀
I've submitted a few reports to Kotlin issue tracker, so feel free to vote for them and maybe even add some info:
- https://youtrack.jetbrains.com/issue/KT-45964
- https://youtrack.jetbrains.com/issue/KT-45960
- https://youtrack.jetbrains.com/issue/KT-45959
I will proceed with you changes hopefully on the next week.
Which changes are vital is still the open question. Could you somehow determine which ones give the most boost?
Also, if it's possible to open a separate PR for every change, I will appreciate it much.
By the way, the current optimization may break some things. I try to using OffscreenCanvas to improve double buffered render logic, but dose not succeed. The transferToImageBitmap will make the buffer canvas empty. /
Maybe I should revert those change.
There is still some space for improvements.
- offload the websocket communication & serialization/deserialization to WebWorker.
- Using WebWorker to render OffscreenCanvas, then dump image bitmap to the front canvas.
The current optimization makes the web client usable. I may not have time to go further.
@wpc009 are you still working to merge it to master ?
@wpc009 are you still working to merge it to master ?
No, This PR contains lots of Hacks which should not be merge into master.
I propose this PR only to provide some idea on perf improvement.
@wpc009 are you still working to merge it to master ?
No, This PR contains lots of
Hackswhich should not be merge into master. I propose this PR only to provide some idea on perf improvement.
ok .thanks . one more question ,do you still remember the server version you can build with ? i want to see the effect. i tried with some server like 1.0.0 1.1.0 seem can't use .