On 24 November 2016 at 19:55, tim Rowledge <tim@rowledge.org> wrote:

> On 23-11-2016, at 11:12 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
> In DisplayScreen class >> startUp we have the following:
> startUp  "DisplayScreen startUp"
>     Display setExtent: self actualScreenSize depth: Display nativeDepth.
>     Display beDisplay
> Does it make sense, to always trying to create a display in startup time?

No, it doesn’t. Ideally no resource should be started up/connected/created/tweaked until and unless it is actually needed by the running system.

Obviously, the default setup for a Smalltalk tends to be the GUI IDE and it’s so very easy to slide into the assumption that graphics and sounds and windows must be started up no matter what. We all do that kind of thing, even when we know we shouldn’t. You can make some reasonable arguments that an image configured to be an IDE ought to open a window or two during start up since that is kind of its raison d’etre.

My small protest against this is/was the RISC OS VM not creating a UI window until the first display update was made. At least that meant that an image with no need of a graphical UI never needed to do anything other than not display anything on the Display.

I’d say that all the host window IO related stuff ought to go into an extend HostWindowPlugin and be removed from the core. I’d also prefer all the plugins to be external, even though I know there can be a tiny performance hit, depending upon the details of how the OS does late binding. The unix VM kinda-sorta does some of this with the C++ usage and vm-display-xxxxx modules etc, but I think a lot more needs doing. And of course, the image needs lots of work to make good use of it. Until you have images that don’t need display/sound/sockets/whatever, there isn’t a lot of point worrying about the vm side.

In Pharo we did a special OSWindow layer, that allows platform-independent access to host window setup & manipulation etc.
There are multiple drivers , each for own platform/implementation, like SDL2, as well as a special NullWindowDriver, that simply passing all UI-related requirests to /dev/null ..
This is done so, to ensure that image could run fine even if VM is missing host window support or can't find any plugins etc, since historically too much code in image is done with 
assumption, that its always there.. In that case, we can always switch to null-window driver so all user-code would still function without knowing that there's actually no host window created etc.

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: LA: Lockout Access

Best regards,
Igor Stasenko.