SS: App resolution change, bad graphics state?

[rakslice]

Changing resolution/mode sometimes leaves the system without functional image decompressors, which causes QuickTime PictureViewer to error with -8988 (codecOffscreenFailedErr) and apps that use such images in panels to fail to render properly. The condition is temporary; subsequent resolution/mode changes have a chance of making them work again.

How to reproduce:

1. With an image open in PictureViewer, or iTunes 2.0.4 running with visualization on (Cmd-T),
2. Change the screen resolution, colour mode, and gray/colour setting; try making changes with the monitors control panel and the control strip; try launching sessions of the monitors control panel under different conditions.

---

Initial issue:

Testing iTunes 2.0.4 visualization in Mac OS 9:

If iTunes has already been used in the current Mac OS session but the resolution has been changed since,

• the brushed metal background texture of the window fails to draw, it is just solid white
• when visualization is turned on even in default non-full-screen mode it fails to display - there is just a black square

Visualization full screen mode doesn't work unless the Mac resolution is 640x480 (I expect this is because it is the only case where it doesn't try to switch resolutions for it)

[rakslice]

There is a similar behaviour with QuickTime's PictureViewer, if the resolution has been changed since startup, erroring (usually with error -8988), sometimes followed by a crash. However notably unlike #27, it doesn't affect some applications that use QuickTime JPEG PICT resources like Audion.

[rakslice]

This only happens when switching the resolution with the control strip... [Not quite, see note below]

[rakslice]

(Testing in kanjitalk755 win32 https://github.com/rakslice/macemu/commit/0b9b6401d6bd4246b4d58d395974c787ffc108c1)

Also testing PictureViewer in Mac OS 7.6.1 with Quicktime 4.1.2, I find a similar situation where the most recent resolution change can lead to error -8988 , but with a couple of differences.

• Like in Mac OS 9 w/ QT5, in Mac OS 7.6.1 changing the resolution using the control strip can lead to the error, changing the resolution using the Monitors & Sound control panel never leads to the error [Not quite, see note below]
• When there is a first resolution change at startup because the previously configured resolution in Mac OS is different than the boot resolution controlled by the sheepshaver_prefs, in Mac OS 9 that resolution change never leads to the error, but in Mac OS 7.6.1 that resolution change always leads to the error
• In Mac OS 7.6.1, leaving PictureViewer open during the resolution change with the control strip prevents it from leading to the error; even if PictureViewer is launched before the resolution change and exited afterward without opening any files, subsequent PictureViewer runs at that resolution will work instead of erroring. In Mac OS 9 it makes no difference whether PictureViewer is open during the resolution change with the control strip.

[rakslice]

No, it doesn't happen only when switching resolution with the control strip, it also happens when switching resolution with the monitors control panel depending on the state when the monitors control panel opened...

Note that unlike resolution, switching colour mode with the monitors control panel always works even if switching resolution with the same control panel instance would lead to a bad state

[rakslice]

I can't figure out the condition that leads to a monitors control panel that gives bad resolution changes.

[rakslice]

[this ended up not being important; the hardcursor cursor jumps are a separate issue that is just the result of the implementation using the wrong SDL call and probably not having been tested before the default was changed]

Due to the clicks on icons repositioned by these resolution changes leading to off-screen jumps in #36, I think I need to ask a stupid question:

Where is the screen in QuickDraw coordinate space? What effect does changing the resolution have on that? Is the right thing happening to coordinate space after a resolution change in SS? Does the video driver have any responsibility to do any bookkeeping for that?

[rakslice]

Similar behaviour is mentioned in this ancient forum post https://www.emaculation.com/forum/viewtopic.php?t=7138 The commenter correctly notes that this is codecOffscreenFailedErr, based on the presence of this error code by that name in the QuickTime API reference error list. http://web.archive.org/web/20040305060523/developer.apple.com/documentation/QuickTime/APIREF/SOURCESIV/errorcodes.htm

The QuickTime 3 version of PictureViewer, stock in Mac OS 8.5, actually gives an error message for this error instead of the error number:

Couldn't display "Sample Image" because a suitable decompressor could not be found.

I just tried to reproduce the problem in my qemu ppc 2019-04-24 build Mac OS 9.2.x install, and couldn't! That version of qemu's ndrv has basically no support for <256 colour modes, but almost any mode switch with the control strip hits the bug in SS, so it's quite something that mode changes are working in qemu.

Scouring its ndrv for any difference that might account for the difference, I found something it is initializing that SS isn't: https://github.com/qemu/QemuMacDrivers/blob/90c488d5f4a407342247b9ea869df1c2d9c8e266/QemuVGADriver/src/DriverQDCalls.c#L585

[rakslice]

I couldn't reproduce this issue in BII (tested Mac OS 7.6.1 with control strip and QT 4.0.3, which have the issue in SS).