I have a complicated layout with Borderlayouts within Borderlayouts. As well I have a lot of data which constructs a large DOM. I can remove many of my Borderlayouts but when I resize the browser window the layout (not sure which one) will redraw the whole page which takes a while to render (10-12 seconds). I noticed that it will render multiple steps during the resize of the window.
How do I prevent the relayout and render while window resizing. I only need it to redraw and render when the user releases the mouse. Before I investigate Event.stopPropagation() and hope it works client side, maybe there's a setting or strategy. I couldn't find anything Also I can't enable Render On Demand I don't have EE, just a FYI.
Thanks in advance for any help.
which zk version?
do you register any onAfterSize listener?
It's usually no easy, straight-forward solution for a performance problem. The solution depends on the root cause/bottleneck. It could be server-side or client-side. Please find the performance bottleneck first by reading https://www.zkoss.org/wiki/ZKDeveloper%27sReference/PerformanceMonitoring/StepbyStepTrouble_Shooting
After you share with us about your finding, then we can discuss which solution suits your case.
Thanks for the tips. The version is 9.5 CE. I have investigated the and it's not serve side. My laptop has a lot of ram and CPU. I made this zkfiddle to illustrate:
https://zkfiddle.org/sample/2qnpsco/3-resize-issue-and-redraw-during-window-resize
Wait for the Borderlayouts and content to render on screen. Now restore (un-maximize) your browser window and start to resize it. Resize the window in a jerking motion, 3-4 and release the mouse. Notice the Borderlayout performs multiple recalculations (2-3) of the children before occupying the correct space. You can also collapse the East and North panels but the effect is not as pronounced.
From Chrome dev tools my code/application, and the fiddler, the time spent is in Scripting and Rendering, and that's it. In network and other tabs it's not the server or other factors. This is why it's important to wait until the page is fully rendered before testing.
Yes the content is a large DOM. But, I tested the fiddler with 9.0.0.1 and it's much better and more fluid. But I didn't performance test.
What I'm hoping for is to delay the recalculation until the mouse release event, if possible.
Thanks again for the support.
Thanks for the zkfiddle.
After I do a performance profiling, it's caused by size reset and applying css flex for many <hlayout height="100%" hflex="1" >
It looks like ZK does something more. I will post a bug to improve this case.
If this is your use case, the workaround would be to replace hflex="1" width="100%" if it gives you the same result.
What you suggest "to delay the recalculation until the mouse release event", which is impossible. Since you can't detect a mouse down when resizing a browser because it clicks outside of a web page.
But comparing chrome profiling results between 9501 and 9001, they look quite similar for these 2 versions.
In both cases, beforeSize() and fixCSSFlex() consume most of the time.
If you feel 9.0.0.1 is much better, could you do client-side profiling?
Thanks for the follow up. I tested with the fiddler link I posted and using Chrome debug tools version 9.0 was faster. But my biggest tests was visual inspection. If I change the fiddle to 9.0 and perform the same dragging the refresh is better and faster. I'll try and pull up some numbers.
54patman ( 2020-12-30 03:13:35 +0800 )editPlease try 9.5.1.FL.20201230-Eval that improves the rendering performance.
the repository you found is CE, please download EE Evaluation from a different repo http://mavensync.zkoss.org/eval/org/zkoss/zk/zk/
hawk ( 2021-01-08 11:16:51 +0800 )editAsked: 2020-12-15 07:13:10 +0800
Seen: 27 times
Last updated: Jan 12
Tags
People
Badges
Help
