[Vm-dev] [commit][3665] Squeak is actually not DPI aware (yet?).

Tobias Pape Das.Linux at gmx.de
Mon May 2 14:56:40 UTC 2016


Hi Eliot,

On 06.04.2016, at 18:14, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Tobias,
> 
> On Thu, Mar 31, 2016 at 12:01 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> Hi Eliot,
>> 
>> On 31.03.2016, at 06:53, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> >
>> > Hi Tobias,
>> >
>> >    card to say more about this?  I had explicit requests to add this with the given settings and have heard of no complaints yet.  But you disable it below.  Are you sure you're doing the right thing?
>> 
>> The effect of <dpiAware>true</dpiAware> is that Windows expects the application to
>> handle the actual dpi of the screen the application is currently on.
>> 
>> On typical displays, there's no change, but hi-dpi displays (like a MS Surface, or Retina Macs)
>> have a higher DPI and Windows in this case does not do anything special.
>> In effect, the picture is just tiny, fonts near unreadable.
>> 
>> While some people (also people I know) prefer this tinyness, it is actually startling for
>> new users and "the average" user.
>> 
>> If <dpiAware>false</dpiAware> is set, Windows handles the screen DPI and upscales
>> the backing store so that everything looks similarly big on screens of different DPI.
>> This is (imho) the expected behavior.
>> 
>> People preferring the hidpi variant easily can set the dpiAware entry (thats, eg, what
>> Marcel does for his projects sometimes). The other way round, expecting average/new
>> users to _disable_ that is probably a bad idea.
>> 
>> Hence the change.
>> 
>> Once we have
>>         - VMs actually reacting to Screen-DPI-changes and
>>         - Emitting DPI-changed-Events to the Image and
>>         - The image actually does something useful with this event
>> I'll happily change that back. But that time has not come yet.
>> 
>> Best regards
>>         -Tobias
>> 
> OK, but the README (generated by scripts/uploadvms) states
> 
> "     Windows
>      The Windows VMs are "dpiAware", which means that by default the display is
>      not scaled and display pixels are mapped 1 to 1 to the screen.  If this
>      behaviour is not desired you can enable scaling by either editing the
>      relevant manifest file (e.g.  Squeak.exe.manifest), changing the "true" in
>      <dpiAware>true</dpiAware> to "false", or simply deleting the manifest file. "
> 
> So I'll change this.  (But under protest; it strikes me that it's much easier to delete a file than edit it, so those wanting non-dpiAware Windows VMs have a simple option, whereas those wanting it have to edit the damn file).
> 
> In any case, some enterprising soul could add code to the image that would change the setting and relaunch; that would be very nice.  In fact, why not do this, and revert the dpiAware setting?  The Windows VM has been this way for some time, and it's perhaps better to fix the issue flexibly (by providing an in-image menu pick that will try to edit the VM's manifest file).

That's my goal, the image reacting to DPI changes. But we're not there yet.
I'll make a proposal soon.

> 
>> PS: I also want DPI-awareness for the Mac VM, btw.
> 
> (IANOERAGE)  What does this mean?  A simple approach might for the VM to do scaling by integer factors, avoiding fuzziness but yielding chunky pixels.  A better approach is simply to have the image choose larger fonts and larger window sizes in proportion to some "reference" window size such as 1600x1080 or 640x480 (how quaint).  What I expect it /not/ to mean for a while, is replacing the graphics model with a vector graphics one.  Pharo is doing this and we can steal the work when we have energy (and black masks).
> 
> What does this cost?  Ho much VM work is there in Linux, Windows and Mac VMs to provide a "useful" form of being dpi-aware?

OS X has some very idiosyncratic ways of interacting with Screens of different DPI.
Note that I am not (yet) speaking about the image but only the VM.
I have a bunch of patches to the Cocoa (aka iOS) platform in the pipeline and will post soon.

Best
	-Tobias


> 
> (IANOGE = I am not even remotely a graphics expert = those of you with a clue, please weigh in and make some decisions, help with crafting a graphics trajectory)






More information about the Vm-dev mailing list