[Pharo-dev] The HiDPI Issue

Ben Coman btc at openinworld.com
Sat Feb 16 01:07:47 EST 2019


On Sat, 16 Feb 2019 at 00:53, Eric Gade <eric.gade at gmail.com> wrote:

> Hello,
>
> I know that others have posted about this before but I wanted to get the
> current status.
>
> I've recently had to buy a new laptop that came with a HiDPI display.
> Generally (especially on Linux systems) this makes Pharo unusable. Though
> there are font size increase and scaling options in the Pharo system
> settings, these do not work as a solution -- buttons are still tiny, there
> is inconsistent scaling behavior across morphic, etc. The overall problem
> can be described as: in Pharo, one pixel equals one "point," and so the
> interface is incredibly small on these HiDPI screens (3k etc).
>
> These HiDPI screens are becoming more common, both as laptop and as
> external displays. Their main advantage is that they can render text very
> crisply. In the HN post announcing the release of P7, there were one or two
> complaints about this issue. It does make it hard to demonstrate to others
> (as I do often) the power of developing in Pharo.
>
> Here are some questions I have about this issue:
> 1) What is the current state of affairs in dealing with this issue, if any?
>

This is what I understand from observing mail list discussions...
For a long time Pharo has been wanting to move windowing out of the VM and
into the Image and utilise FFI for the library calls.
The Pharo 8 roadmap (
http://forum.world.st/Roadmap-for-Pharo-8-0-td5094949.html) includes using
a true headless VM
with zero windowing code as the standard Pharo VM and have windowing done
from the Image.  This should open up
the possibility of you contributing by coding and debugging at the Image
level.  So stay tuned.



> 2) Would this require VM changes (I assume it would)? If so, what might
> those entail?
>

Yes. And, I don't know.
Anyway, this question may end up mute if native-windowing is more exposed
to Image-side as described above.


3) If this does require VM changes, I assume the Squeak people would want
> in on it?
>

I'm sure they would broadly want the functionality. However Squeak is
concerned more about backward compatibility than Pharo.
They may be more conservative about following the same path as Pharo.
Perhaps once Pharo has broken the ground and proved the concept Squeak
could look at how to adopt it in a compatible way.
For example, I wonder if its possible to isolate Squeak's VM side window
initialization to a single function call
that is invoked or not depending on a flag in the Image - which Pharo
Images can have set moving forward,
and remains unset for Squeak Images.


4) Is the current plan to wait for Bloc to resolve these issues and/or
> would switching to Bloc resolve these issues at all anyway?
>

I'm not up to date on Bloc progress.
But with the move to a headless VM, all old problems get thrown away (i.e.
so we can make new problems ;)
so HiDPI is likely to have the opportunity to be addressed this iteration.



> 5) Related -- where can one start to learn about current VM architecture
> and development practices?
>
https://hal.archives-ouvertes.fr/hal-01883380/document
https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/



> That said I'm not here to just bellyache. While I don't have any VM
> experience, I'm willing to jump in and try to work on it if someone can
> point me in the right direction. Or perhaps this is too specialized a
> task...
>

Hopefully it will become less specialised soon.
Would you volunteer for early testing of windowing driven from Image side
of headless-VM ?

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190216/20a02c40/attachment.html>


More information about the Pharo-dev mailing list