Reducing CPU usage when emulation window is inactive

[mark_k]

A couple of suggestions for features which could allow WinUAE's CPU usage (but not the emulated machine speed) to be reduced when the window is inactive:

• Ability to specify an alternate refresh (frame skip) setting to be used when the window is inactive. The user could be using another application, but still wants to have the emulation window visible. [Maybe, depending on emulation settings, doing that would increase emulation speed?]
• When the entire emulated display is obscured by another window, stop refreshing it altogether. Start rendering Amiga frames again once part of the display is revealed. (Note that the emulated display could be completely covered but the status bar below might not be. So you'd still refresh the status bar in that case.)

[meynaf]

I second that.

In addition it would be good to detect whether the screen has changed or not, to prevent unneeded refreshing (i heard some mac emu on the amiga does this with the mmu).
Seeing permanent 25% cpu use while the Amiga is totally idle isn't exactly sexy.

[Toni Wilen]

It isn't that simple. When it is finally known that display has changed, about 2/3 of the display emulation is already done.. Final bit (planer to chunky, sprite merging and conversion to host color depth) is very simple part.

Don't ever try to compare Amiga with some basic system that does not have anything like a copper or hardware sprites.

EDIT: RTG modes already use host MMU write detection trick. It can only work with RTG modes because they are 100% predictable, no copper tricks and splits.

[mark_k]

A small addition: the ability to specify a very large frame skip value for when the window is inactive could be useful. E.g. user is installing Linux or NetBSD which takes a while, they might choose to only have the display refreshed once per second, which would be good enough to see when user input is needed.

[Toni Wilen]

Does it really make any noticeably difference? Static non-copper trick screen should be detected as nothing much changing and frame skip can't skip early parts of display emulation anyway because it would only break compatibility too bady.

[mark_k]

Testing with a config which uses fastest possible CPU, JIT, CPU idle set to max (my usual config which I use with Workbench). Screenmode is HighGFX 1024×768. Workbench loaded, emulated system idle. On Linux/Wine, the WinUAE CPU% indicator reads 29%-33% at frame skip 0, 23-26% at frame skip 9.

Maybe some demo with lots of copper effects could show a larger difference?

An A500-like config with cycle-exact unchecked, running CELTIC-MultiscrollerScroller demo.
27%-30% frame skip 9
43%-52% frame skip 0
(with my laptop's CPU locked to 800MHz)

Large frameskip could be useful if user has demo running, listening to the music, but the demo waits for a mouseclick at the end of each part.

[meynaf]

Originally Posted by Toni Wilen

Does it really make any noticeably difference?

It's worth if filters are used. Some take a significant cpu use.