What is supposed to be the effect of DisplayScreen class>depth:width:height:fullscreen: ?
This is a very curious primitive. First, there are no senders so I have to wonder if it is actually of any value.
Secondly, just what is it supposed to do? Setting the fullscreen flag to true and the width or height to some number not equal to the full screen size does what exactly? Should the prim ignore w & if fullscreen = true? Setting the depth should do what? It can't set the depth of the Display object - that has to be done via methods like DisplayScreen>setExtent:depth:. I suppose it could possibly set the bitdepth of the OS window buffer (where one is used) but that seems like it is private to the VM.
I can see a value in having a prim that programmatically sets the window size (which is why I ended up looking at this) but I don't think this prim is entirely suitable nor even properly defined nor even widely implemented. Any thoughts anyone?
tim
Hi Tim,
The primitive you're talking about has basically two purposes. It depends on whether the fullscreen flag is true or false.
Mode A: fullscreen == false This requests to change the size of the hosting window in a windowed environment. In a non-windowed environment (such as using /dev/fb) it is allowed to fall back to mode B.
Mode B: fullscreen == true This requests to change the size of whatever it is Squeak is currently displayed on - in other words, it means that the primitive (if supported) should in fact change your monitor resolution (or whatever the equivalent) to allow, for example, games or similar "fullscreen activities with fixed resolutions" to take over the entire screen in a well-defined combination of display size and depth.
As the hosting environment may support a change in depth in addition to the resolution, the depth is passed into the primitive. Therefore, if you request 640x480x16xfullscreen on a platform which supports it then your screen should switch to 640x480x16 with Squeak being the only, fullscreen visible thing in it.
However, if the hosting environment does not support changing the screen resolution it is allowed to fall back to mode A (e.g., change the resolution of the window or somesuch) as the primary request of the primitive is for a certain resolution. The depth and the fullscreen flag are "optional" - e.g., may be ignored if the platform does not support changing any of these.
The primitive should fail only if: * the platform has no way to do mode A (not implemented), or * the platform can support mode B but the parameters passed are invalid (e.g., requesting 1024x768x32xfs on a platform which only supports 640x480x8xfs).
[Note: If a platform supports mode A and doesn't support mode B, then it should essentially never fail and just change the window resolution].
BTW, the reason this is just one primitive is that for Squeak the effect is the same - the size of what's reported by DisplayScreen>>actualScreenSize will change to whatever was requested if the primitive succeeds. Everything else is optional and allows for some attributations which are very handy if you happen to know you're likely to run in a "window environment" - and the fallback positions do allow you to get a reasonable approximation of what you want if the primitive is not capable of dealing with screen resolutions directly.
Clearly enough defined?! ;-)
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Monday, March 31, 2003 8:55 PM To: squeak-dev@lists.squeakfoundation.org Subject: What is supposed to be the effect of DisplayScreen class>depth:width:height:fullscreen: ?
This is a very curious primitive. First, there are no senders so I have to wonder if it is actually of any value.
Secondly, just what is it supposed to do? Setting the fullscreen flag to true and the width or height to some number not equal to the full screen size does what exactly? Should the prim ignore w & if fullscreen = true? Setting the depth should do what? It can't set the depth of the Display object - that has to be done via methods like DisplayScreen>setExtent:depth:. I suppose it could possibly set the bitdepth of the OS window buffer (where one is used) but that seems like it is private to the VM.
I can see a value in having a prim that programmatically sets the window size (which is why I ended up looking at this) but I don't think this prim is entirely suitable nor even properly defined nor even widely implemented. Any thoughts anyone?
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Lightbulb over his head is burned out
"Andreas Raab" andreas.raab@gmx.de wrote:
Hi Tim,
The primitive you're talking about has basically two purposes. It depends on whether the fullscreen flag is true or false.
[snip]
Clearly enough defined?! ;-)
Almost; if the current situation is 16 bpp NOT fullscreen and the primitive args are, say, "8, 800, 600, true" I imagine the intention would be to change to fullscreen and try to reset the screen size and bpp? And conversely if the current situation is fullscreen and the relevant argument is false, one should exit fullscreen as well as trying to change the window size. In other words, is the intent of the fullscreen flag to _alter_ the fullscreen status or merely to _reflect_ a status previously set via ioSetFullScreen()? What about the bpp in this case? And should the screen resolution be returned to what it was previously - and how far ought one 'stack' the values of 'previous'?
Assuming I have a machine that can manage it, what should the result of starting from 16bpp, 1024@768, fullscreen OFF (say screen is 1280@1024) applying 16,1200, 1000, OFF {guess - change window size} applying 32, 1024, 768, ON ? {guess - go fullscreen, change screen size/depth} applying 32, 1024, 768, OFF {guess - ignore depth change}
How about first applying 16, 1024,768, ON and then 16,1024,768, OFF? {guess - I'd want it to return to original screen resolution and window size}
Or 16,1024,768,ON then 32,800,600,ON and 16,640,320,OFF? Which screen resolution would one return to? 1024@768 or the 'original' 1280@1024? Or stay at 800@600 and 32bpp?
It can be a real pain to try to define these things properly but it's even more of a pain to try to implement the prim without a good defn of the intent! Not to mention that some prims are expected to return true/false to say if they failed and others are expected to use primitiveFailed()....
tim
Tim,
if the current situation is 16 bpp NOT fullscreen and the primitive args are, say, "8, 800, 600, true" I imagine the intention would be to change to fullscreen and try to reset the screen size and bpp?
The intention of the fullscreen flag is: We would *like* to be the only thing visible on the screen with that particular resolution/depth *if possible*. If we can't, the we still expect to get that particular resolution, unless the primitive isn't implemented or that particular combination of parameters will not work.
And conversely if the current situation is fullscreen and the relevant argument is false, one should exit fullscreen as well as trying to change the window size.
Yes.
In other words, is the intent of the fullscreen flag to _alter_ the fullscreen status or merely to _reflect_ a status previously set via ioSetFullScreen()?
The primary request is for *resolution* not for fullscreen status or depth. Therefore, if you request "8, 800, 600, true" then it is *faulty* behavior to go to fullscreen unless you can provide this particular resolution.
The primitive doesn't say anything about "altering" the fullscreen status - this may or may not be the case. It is *requested* to change the fullscreen status if possible but if it isn't the primitive should rather resize than fail (as it is much easier to resize and the effect is close enough). If some app wants to know if the request succeeded, it can query the fullscreen flag to see if the request was in fact handled in the way it wanted.
What about the bpp in this case?
Err, in what case?
And should the screen resolution be returned to what it was previously - and how far ought one 'stack' the values of 'previous'?
Just one level: The level at which we first went to fullscreen mode. The idea is to temporarily change resolutions (such as for games etc) not permanently. Therefore you always return to what was initially the case.
Assuming I have a machine that can manage it, what should the result of starting from 16bpp, 1024@768, fullscreen OFF (say screen is 1280@1024) applying 16,1200, 1000, OFF {guess - change window size}
Yes.
applying 32, 1024, 768, ON ? {guess - go fullscreen, change screen size/depth}
Yes. If you don't do "mode B" (that is resolution switching) then you simply resize. If you do mode B but can't do 1024x768x32 you fail.
applying 32, 1024, 768, OFF {guess - ignore depth change}
Go back to 1280x1024 (which was the resolution before we went fullscreen) get out of fullscreen, resize to 1024x768. Depth is ignored without fullscreen.
How about first applying 16, 1024,768, ON and then 16,1024,768, OFF?
Your window title appears again and your resolution is unchanged from what it was before you went fullscreen.
{guess - I'd want it to return to original screen resolution and window size}
Not the "original" window size but rather 1024x768 as per your request.
Or 16,1024,768,ON then 32,800,600,ON and 16,640,320,OFF? Which screen resolution would one return to? 1024@768 or the 'original' 1280@1024?
Always the "original" when you go out of fullscreen.
It can be a real pain to try to define these things properly but it's even more of a pain to try to implement the prim without a good defn of the intent!
Well, the intent is pretty simple ;-) Just give people a way of making things at certain resolutions without screwing up their environment permantly. Try to get as close as you can to a reasonable interpretation of the request if it can't be done "properly". If you think it through from that point of view the behavior becomes perfectly well-defined.
For example, what would be the reasonable behavior for a game which is best run at 640x480x32 with a few settings pages designed for 800x600x16 where you want to switch forth and back?! What would people expect when they start the game, when they run it, when they exit it? What would be the "most reasonable thing" you can do if you don't support resolution switching? Here's the set of mode switches you're likely to see:
* upon start: 800x600x16[false] for "welcome/splash/whatever" * when entering game: 640x480x32[true] * when going into settings: 800x600x16[true] * back to game: 640x480x32[true] * upon quit: out of fullscreen, bye, bye
It's simple, really ;-)
Not to mention that some prims are expected to return true/false to say if they failed and others are expected to use primitiveFailed()....
I actually don't care whether you #primitiveFail() or return true/false as long as the result is that if the primitive "succeeds" then the resolution of Squeak's main display has the requested resolution (not including depth/fullscreen). That's the thing that counts most here. If you *do* mode switching then I expect the primitive to either respect the settings provided (including depth) or to fail if it can't do this combination (but some other).
Cheers, - Andreas
Well, the intent is pretty simple ;-) Just give people a way of making things at certain resolutions without screwing up their environment permantly. Try to get as close as you can to a reasonable interpretation of the request if it can't be done "properly". If you think it through from that point of view the behavior becomes perfectly well-defined.
That's ok then. So resolution first, fullscreen if it can be done, depth optional if it can be done. Remember original screen resolution when entering fullscreen and return to it when exiting fullscreen. Fail if you can't get 'reasonably' close where 'reasonable' is not well-defined.
Not to mention that some prims are expected to return true/false to say if they failed and others are expected to use primitiveFailed()....
I actually don't care whether you #primitiveFail() or return true/false as long as the result is that if the primitive "succeeds" then the resolution of Squeak's main display has the requested resolution (not including depth/fullscreen).
Not so much an issue related to this particular prim as a more general annoyance. We need to be more careful and consistent with these things. Compare ioSetDisplayMode() which _must_ return true or false with ioSetFullScreen() whose return value is ignored and we have to primitiveFail(). At least we need to document which is meant somewhere reasonable! Like so much else...
tim
Tim,
Well, the intent is pretty simple ;-) Just give people a way of making things at certain resolutions without screwing up their environment permantly. Try to get as close as you can to a reasonable interpretation of the request if it can't be done "properly". If you think it through from that point of view the behavior becomes perfectly well-defined.
That's ok then. So resolution first, fullscreen if it can be done, depth optional if it can be done. Remember original screen resolution when entering fullscreen and return to it when exiting fullscreen. Fail if you can't get 'reasonably' close where 'reasonable' is not well-defined.
"Reasonable" is perfectly well defined. It means: If you don't do something all (such as resolution or depth changing) are you free to silently ignore that particular aspect. If you do support it at all, then you either do it right or you fail.
If I request 800x600x32 fullscreen and you don't do resolution switching, you can ignore the fullscreen/depth request. If you do resolution switching but don't do depth switching, then you may ignore the 32bpp, but you may NOT ignore the 800x600 fullscreen request. You either get me into fullscreen 800x600 - or you fail. If you do both, resolution and depth switching then I expect to get 800x600x32 - or you fail.
Simple. Really.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Tim Rowledge