What is supposed to be the effect of DisplayScreen class>depth:width:height:fullscreen: ?

Andreas Raab andreas.raab at gmx.de
Tue Apr 1 01:14:40 UTC 2003


> 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.


> 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 at 768, fullscreen OFF
> (say screen is 1280 at 1024)
> applying 16,1200, 1000, OFF {guess - change window size}


> 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

> 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 at 768 or the 'original' 
> 1280 at 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).

  - Andreas

More information about the Squeak-dev mailing list