1.7 Moving window to other monitor is SLOW

[cyanity]

in 1.6 and before, we could move our windowed app between (multiple) displays/monitors with no delays (XP, sp3). Then when we plugged in 1.7, and tried to move our app between displays, Ogre now takes a minute or two, and several hundred meg (sometimes crashing due to lack of memory) before the moved window is ready and rendering. (we can swap .dll's easily, very repeatable, lots of machines, nvidia and ati). Any ideas why? What do we have to add to the 1.7 initialization to get our former performance back?

During the minute or so 'hang', the log mentions things like:
18:14:06: Texture: arrow-right-icon32x32.png: Loading 1 faces(PF_A8R8G8B8,36x36x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,36x36x1.
and
18:14:06: D3D9 : Loading 2D Texture, image name : 'small_bin.dds' with 8 mip map levels
and
18:14:51: D3D9 device: 0x[10817880] destroy. Releasing D3D9 texture: UltiSimDynTexture_64
18:14:51: Released D3D9 texture: UltiSimDynTexture_64

etc. for a minute or so, until the moved window is finally ready and rendering again.

Also, while we're waiting for the window to 'come back up', the memory usage goes through the roof: E.g.,
- our app loads, and it's 500 MB
- do min/restore, and now it's 100 MB (and renders fine)
- Slide the window to the other display, and after the minute or so delay, it's back up to 500 MB.
- If we move the display w/o the min/restore (i.e., when it's already at 500MB, ) it goes up to 900 MB during the minute or so that ogre is crunching, then goes back down to 500MB once the window is ready.

If it runs great with only 100MB, then why the intermediate 500 (or 900!!) MB?

I've tried setting Manager MemoryBudgets with no success (anyway, MemoryUsage claims only 20-30MB is being used).

Any ideas?

thx.

[Matheus Martino]

It looks like you are using Windows XP SP3, and you can test with diferent machines, right?

Since that forum does not provide to us some magic orb that alow us to see your code without you showing it to us, we are unable to tell you what is wrong with it.

What i can tell you is that i'm using WinXP, Ogre 1.7, Nvidia 8600 and two monitors and i don't have that problem. In fact my apps do all the configuration the way the ogre developers want (like in the samples and tutorials), are your app configured started the same way?

[Assaf Raman]

Can you recreate the issue with the sample browser?

[cyanity]

(good to know it sorta works somewhere!)
There is an obvious multi-monitor difference between 1.6 and 1.7, see below - note, we are using 500MB+ just in textures, so if you have less, it'll be faster

The systems below have one graphics card driving two monitors.

1.6: on nv 480 GTX, 'dual screen', render rate is 350HZ on first monitor. Sliding window to second monitor takes no time. Rendering on second monitor is 50 HZ.
1.7: on slightly lesser system, render rate is 250 HZ on first monitor. Sliding window to second monitor takes 20+ seconds. Rendering on second monitor is also 250 HZ.
1.7: if we have nvidia setup our two monitors in "span mode" (lieing to XP, telling XP that the first monitor is 4kx1k), then sliding the window from monitor to monitor takes no time - windows doesn't know enough to say "hey, your changing monitors, you may have to reload to the 'other' graphics card!"

So it seems that on 1.6, sliding windows around really didn't reload the graphics card - it just did mem blits to the other monitor (which accounts for the dramatic slowdown in frame rate)
And in 1.7, multi-monitor got put in to run the graphics directly on the second 'card'/monitor - that accounts for the full speed. That also explains why there is a 10-60 pause on moving the window - Ogre is reloading the 'other' monitors driver.

I.e., it looks like we either get slow frame rates on the second display (1.6), or slow 'switch monitors' (1.7). Oh well ...

Any way to improve the reload speed when switching monitors? Does Ogre *really* have to reload when it's physically the same single card? Any suggestions on what kinds of textures might reload faster? (our 480 takes 8 seconds, other cards take a minute or more).

thx.

[Assaf Raman]

Ogre *really* have to reload when it's physically the same single card.
The reason is that in DX every monitor is a "device".
What you can do it starch the two monitors in the driver options to be a single monitor on some GPUs, but that is about it.
There is also an option to create everything on all the devices - then you won't have a wait.

[cyanity]

yes, you can see similar behavior w/ the sample browser - but it needs lots of textures to be visible. Watching the task mgr / memory usage is one way to 'see' it even for small loads.

using mogre demo bsp (one of the larger ones):
the loaded app is 70MB, minimizes to 2MB, restores to 7MB. Move to 2nd monitor, and it memory usage goes back up to 30MB over a few seconds. With only 20MB or so of textures, it is rather fast, so don't blink.
If you split the window across screens, it goes up to 40 MB within a few seconds.

Note: when it starts, its at 70MB or so. If you switch screens w/o the minimize, it'll bounce up to 80 then back down ... if you split it across screens, it goes and stays at 90 (all numbers approx). The 'minimize window' does a lot to reduce the memory - it'd be great to know how to keep the mem that low during loads etc!

With ogre set to verbose, the time/processing is more visible. With 500MB of textures, it's even more visible

So it seems that Ogre's multi-monitor support (DX) loads the driver per monitor, that takes a while, and the driver is forgetting to release its scrap memory w/o a 'minimize' to help out. I don't know if GL is any different.

Shame we have to load twice the data for a single monitor to drive two monitors ... (unless you trick Windows by using Span mode or (likely) eyefinity)

So, any settings you'd suggest for speeding up the reload?

thx.

[cyanity]

Ogre *really* have to reload when it's physically the same single card.
The reason is that in DX every monitor is a "device".

Ah, good to have that verified. It just surprised us (the 60 second delay) when we upgraded to 1.7 ...

What you can do it starch the two monitors in the driver options to be a single monitor on some GPUs, but that is about it.

Yep, the 'span' works well - we're rewriting our demo procedures to tell them how to set that up. But it still eats memory ...

There is also an option to create everything on all the devices - then you won't have a wait.

That may be useful - how do we set that option? Does it work for 'windowed' apps, or only full screen? Any helpful examples?

Any further ideas for reducing the 'switching window' time overhead?

And, somewhat more important, any suggestions for avoiding the memory usage from blowing up so high during (re)loads? Some way to make it more incremental/purging/reusing? In our case and the Ogre's BSP demo case, its a 5x-10x 'load/reload memory size' vs 'rendering memory overhead (so we can't show scenes that we have the memory to easily run because instead they crash during reload due to the 10x memory (re)loading overhead ...).

as always, thx!