[Vm-dev] Removing most of the windowing code

[Igor Stasenko]

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

>
>
> > On 23-11-2016, at 11:12 PM, Ronie Salgado <roniesalg at 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
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: LA: Lockout Access
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161128/6ae9dd00/attachment-0001.html>