SCUMM: MONKEY2 (MAC): Slow rendering with Macintosh titles on OSX PPC in 2.9.0pre

[dwatteau]

Current Git HEAD on OSX PPC (either 10.4 or 10.5).

Built with GCC 7.5.0 and optimizations.

As an example, the following Monkey2 configurations run fine:

• Monkey Island 2 DOS/English on the same machine
• Monkey Island 2 Macintosh in ScummVM 2.8.x with the same settings

but the following config has performance problems:

• Monkey Island 2 Macintosh on current ScummVM 2.9.0pre

When I play the Macintosh in full screen, the FPS feels slow. Guybrush walking from the right to the left of the screen after talking with Bart & Fink, or Guybrush crossing the Woodtick bridge before meeting Largo, is quite slow and interrupted.

Typing rough in order to disable the smooth graphics effect doesn't appear to fix the problem. I can't say if the issue is related to that, or the new MacGUI interface, or the gamma correction, or something else.

I'm attaching performance analysis output below.

[dwatteau]

OSX Leopard's OpenGL profiler output when running the game

[dwatteau]

OSX Leopard's OpenGL profiler raw output (text format)

[dwatteau]

OSX Leopard's Instruments output when running the game

[dwatteau]

OSX Leopard's Instruments project file -- probably requires an an old release of Instruments (circa Leopard/Snow Leopard?)

[dwatteau]

OSX Leopard's raw 'sample' output (Linux perf equivalent)

[dwatteau]

OSX Leopard's 'sample' output processed with filtercalltree

[dwatteau]

flamegraph output made from OSX Leopard's 'sample' output

[eriktorbjorn]

I think the gamma correction is just a trivial table lookup. There's this in ScummEngine::updatePalette():

	if (_game.platform == Common::kPlatformMacintosh && _game.heversion == 0) {
		for (int i = 0; i < 3 * num; ++i)
			paletteColors[i] = _macGammaCorrectionLookUp[paletteColors[i]];
	}

I'm not sure how to read the debug information you attached, but the Mac GUI could be a culprit, I guess. Every time the palette is changed, it will call MacWindowManager::passPalette() so that it can figure out the best colors to use for the Mac desktop. (That's part of graphics/macgui so it's not specific to the SCUMM Mac GUI.) And for MI2, that can happen a few times per second.

I guess you could test whether or not this is costly by commenting out that line from MacGuiImpl::setPalette():

void MacGuiImpl::setPalette(const byte *palette, uint size) {
	_windowManager->passPalette(palette, size);
}

For the SCUMM Mac GUI I guess it would only actually need to do this right before showing the menu bar. But I don't think there currently is a mechanism for detecting that?

[eriktorbjorn]

I have an idea, but it will have to wait until tomorrow.

Basically, I should be able to only call passPalette() in MacGuiImpl::updateWindowManager() since that function detects when the menu bar goes visible/invisible.

[eriktorbjorn]

Could you check if ​https://github.com/scummvm/scummvm/pull/6253 fixes the slowdown for you?

[Torbjörn Andersson <eriktorbjorn@…>]

In 97ced31:

SCUMM: MACGUI: Optimize Mac palette handling (bug #15492)

Previously, every palette change in a game get passed on to the Mac
Window Manager, which would then have to look up new colors for drawing
Mac GUI stuff. This was fine for some games, but later ones do a lot of
palette animations, which could slow things down.

Now the Mac Window Manager gets the new palette only when it's about to
draw the Mac menu, or when it's about to draw a dialog (since those can
be triggered outside of the menu).

Additionally, the Mac Window Manager now triggers the auto-opening of
the menu in the event handler, not in the drawing code. Otherwise the
menu would be drawn once before the SCUMM Mac GUI could notice that the
menu was visible, causing an ugly color glitch.

[dwatteau]

Thank you very much, erik.

I confirm that disabling the gamma fix call didn't fix the issue, and that commenting out the passPalette() line from MacGuiImpl::setPalette() did make the slowdown go away.

More importantly, your PR 6253 does fix the problem for good, on this device :) It now feels like it used to be on ScummVM 2.8, but with the nice Mac GUI improvements over it!

So, I'm closing this as fixed. Thank you very much!

[Torbjörn Andersson <eriktorbjorn@…>]

In f4567290:

SCUMM: MACGUI: Optimize Mac palette handling (bug #15492)

Previously, every palette change in a game get passed on to the Mac
Window Manager, which would then have to look up new colors for drawing
Mac GUI stuff. This was fine for some games, but later ones do a lot of
palette animations, which could slow things down.

Now the Mac Window Manager gets the new palette only when it's about to
draw the Mac menu, or when it's about to draw a dialog (since those can
be triggered outside of the menu).

Additionally, the Mac Window Manager now triggers the auto-opening of
the menu in the event handler, not in the drawing code. Otherwise the
menu would be drawn once before the SCUMM Mac GUI could notice that the
menu was visible, causing an ugly color glitch.