Ram use in firefox on montage is significantly more than chrome.

[connortechnology]

I think the issue may be that we initially load the image with scale=100. I think we should not display an image until we have calculated the scale.

[IgorA100]

I think we should not display an image until we have calculated the scale.

It won't work that way, because... GridStack will not work properly until the image is loaded. I will think.

[IgorA100]

https://github.com/ZoneMinder/zoneminder/pull/4035

[connortechnology]

Thing is, 35% of 640x480 is very different from 25% of 4k. We know theoretically the # of columns... (if we apply the same auto layout logic in php), maybe we could assume 1920px wide and divide by # of columns...

25% should at least provide a proof of concept in improving the behaviour.

[IgorA100]

You wrote everything correctly. I need this PR only to confirm the fact of reducing memory consumption. If at startup 25% of the memory is used less than at startup at 100%, then I’m on the right track.

[connortechnology]

Am profiling as best I can. Not familiar with the tools. Looks like gridstack is taking a lot of cpu (which is fine cuz it's brief).

Not seeing a huge improvement. Isolated Web Content spikes to 10Gb virtual then settles to 2.7Gb on both this branch and master. firefox-esr is taking 4.6GB ram stable.

[IgorA100]

1920px wide and divide by # of columns...

This is only true for preset layouts. Because in custom layouts, one monitor can be 1800px wide and the other 300px wide.

Not seeing a huge improvement.

I noticed that now (when starting with scale=25%) there is no initial spike in network traffic when loading the page. I can't say anything about memory consumption.

[IgorA100]

I can change the SRC before the monitor starts. But to calculate Scale it is required that all monitors take the correct sizes. GridStack does not send an event when the monitor has stopped resizing or moving. I need to track the change of each monitor and as soon as the monitor does not change its size I have to calculate Scale and execute StartMonitor. I'm thinking of using this algorithm.

[connortechnology]

I am thinking that I should add a feature to zms so that it starts up in paused mode. So it sends and image and waits for CMD_PLAY. This way we don't have to change the url and have the image flash while it reloads.

With custom layouts we already know the exact size desired, right? No need to rescale. For *Wide I am thinking we should just start with a reasonable size based on width like 480px (1920/4). Instead of 25% because 25% of a 640x480 will be unattractive.

[IgorA100]

@connortechnology

I did it! :) I was able to implement the previously described algorithm. In any case, now there is no initial big jump in network traffic when the monitors start. All monitors start with a correctly calculated Scale! Please check #4035

[IgorA100]

I am thinking that I should add a feature to zms so that it starts up in paused mode. So it sends and image and waits for CMD_PLAY.

Yes, this is also a good option.

and have the image flash while it reloads.

Try my PR. There is practically no flash.

[IgorA100]

With custom layouts we already know the exact size desired, right?

Unfortunately no. All sizes are stored in GridStack virtual units and need to be recalculated somehow.

[connortechnology]

The situation is much improved. ram use seems to be a matter of image size * # of streams which makes sense.

The specific test case I have here is a large number of cameras. So scrolled way off screen. I have a branch where I was playing with not loading images that are off screen. I will blow the dust off it.