Opened 3 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#15492 closed defect (fixed)

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

Reported by: dwatteau Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Version: Keywords: macintosh, performance, rendering
Cc: Game: Monkey Island 2

Description

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.

Attachments (7)

gl-calls-monkey2-macintosh.png (72.2 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's OpenGL profiler output when running the game
gl-calls-monkey2-macintosh.txt (41.2 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's OpenGL profiler raw output (text format)
instruments-monkey2-macintosh-running-sample-times-sort.png (108.5 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's Instruments output when running the game
Instruments Monkey2 Macintosh OSX 10.5.trace.zip (302.1 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's Instruments project file -- probably requires an an old release of Instruments (circa Leopard/Snow Leopard?)
scummvm-monkey2-macintosh-performance-sample.prof.gz (10.5 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's raw 'sample' output (Linux perf equivalent)
filtercalltree-monkey2-macintosh-performance-sample.txt (110.0 KB ) - added by dwatteau 3 weeks ago.
OSX Leopard's 'sample' output processed with filtercalltree
flamegraph-monkey2-macintosh-performance-sample.svg (147.8 KB ) - added by dwatteau 3 weeks ago.
flamegraph output made from OSX Leopard's 'sample' output

Download all attachments as: .zip

Change History (13)

by dwatteau, 3 weeks ago

OSX Leopard's OpenGL profiler output when running the game

by dwatteau, 3 weeks ago

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

by dwatteau, 3 weeks ago

OSX Leopard's Instruments output when running the game

by dwatteau, 3 weeks ago

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

by dwatteau, 3 weeks ago

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

by dwatteau, 3 weeks ago

OSX Leopard's 'sample' output processed with filtercalltree

by dwatteau, 3 weeks ago

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

comment:1 by eriktorbjorn, 2 weeks ago

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?

comment:2 by eriktorbjorn, 2 weeks ago

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.

comment:3 by eriktorbjorn, 2 weeks ago

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

comment:4 by Torbjörn Andersson <eriktorbjorn@…>, 2 weeks ago

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.

comment:5 by dwatteau, 2 weeks ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed

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!

comment:6 by Torbjörn Andersson <eriktorbjorn@…>, 2 weeks ago

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.

Note: See TracTickets for help on using tickets.