Retina display and Carbon interface?

[cobata]

Hi,

Regarding: (from here: http://forum.lazarus.freepascal.org/index.php/topic,34885.0.html)
"Another one observation with the Carbon interface is regarding the Form scrollbars:
they are always visible when AutoScroll = true. The problem is with just the horizontal scrollbar, because it cоvers the most of the bottom aligned panel and to can see 22 px in height from the panel, you have to set its total height to be 55 px - this is not the case with the vertical scrollbar and the right aligned panel where to can see 23 px in width from the panel, it is enough to set its total width to be 38 px. - they both in the case when you have an object out of the form client area."

Actually, It seems, that exists a bigger, display resolution problem with Retina display and Carbon interface. Is this solved in Lazarus releases > 1.4.4?

Best Regards

[cobata]

In addition:

1.) If you have Edit: TEdit and:
Edit.Text:='0000';
//Edit.AutoSize:=false;
Edit.AutoSize:=true;
Edit.AutoSize:=false;
The TEdit control is autosized vertically (its height changes), but not horizontally (its width stays unchanged).

2.) If you have Label: TLabel and:
Label.Font.Size:=12;
This Label.Caption looks smaller than the text with the same font size (and same font at all) outside of Lazarus IDE.

[AlexTP]

>The TEdit control is autosized vertically (its height changes), but not horizontally
It is normal. Edit/Combobox align only in vertical size.

What problem with Carbon+Retina? what you mean?

[cobata]

Hi Alextp,

You are right, it is my mistake (regarding TEdit)..., probably because of all the test I did trying to solve the GUI proportional incompatibilities:

The software is developed on Windows with win32/64 XOR GTK2 widgetsets: here compatibility exists - they look equal.
On Mac with Retina and GTK2 widgetset the proportions are kept - they are like those on Windows with win32/64 XOR GTK2 widgetsets.

More concrete:
"Another one observation with the Carbon interface is regarding the Form scrollbars:
they are always visible when AutoScroll = true. The problem is with just the horizontal scrollbar, because it cоvers the most of the bottom aligned panel and to can see 22 px in height from the panel, you have to set its total height to be 55 px - this is not the case with the vertical scrollbar and the right aligned panel where to can see 23 px in width from the panel, it is enough to set its total width to be 38 px. - they both in the case when you have an object out of the form client area."
2.) If you have Label: TLabel and:
Label.Font.Size:=12;
This Label.Caption looks smaller than the text with the same font size (and same font at all) outside of Lazarus IDE.
3.) Some Control.Caption(s) are broken on 2 lines...

I supposed that all those incompatibilities related to the Horizontal/Vertical proportions are related to the resolution and/ or to the Retina display, and that is exactly I am asking for.

Best Regards

[cobata]

It seems all observations are related to controls font size...

[cobata]

OK, All seems related to the controls font Size and its relation with the controls font Height.

For example, for Times New Roman:
in the Win32/64 widgetset, if TLabel.Font.Size = 12 than TLabel.Font.Height = -16. It is OK - the real font size (outside of the IDE) is 12 pt too.
in the Carbon widgetset, the Font.Size to look equal in the IDE and outside of the IDE, we have to set TLabel.Font.Size = 16 than TLabel.Font.Height = -16. It is not OK - because it is equal to the real font size (outside of the IDE) which is 12 pt.
(The Font.Size and the Font.Height are bound to each other.)

What are your suggestions to solve the problem?

[cobata]

If someone is looked in the code, the incompatibility between Win32/64 widgetset with Font.Size/Font.Height = 12/-16 (e.g. Times New Roman) and Carbon widgetset with Font.Size/Font.Height = 16/-16 (e.g. Times New Roman) - both looking equal outside of the Lazarus IDE (where the real font size is 12 pt) is because of the PixelsPerInch property which for Lazarus IDE on PC/ Windows is set/ initialized to 96, BUT on Mac (with Retina)/ OS X is set/ initialized to 72 - ALWAYS!

Why, when on Mac:
>xdpyinfo

screen #0:
  dimensions:    1280x778 pixels (338x205 millimeters)
  resolution:    96x96 dots per inch

and It is on the Retina display (2x)
and on the non-Retina display (1x) - I used EasyRes.

The question is how Lazarus initializes the PixelsPerInch, from where it is getting/ reading its value? Can I push Lazarus to set/ initialize it to 96?

[cobata]

Actually,

I found, what I searched for:
carbonobject.inc AppInit calls GetDeviceCaps:
lazarus\lcl\interfaces\carbon\carbonwinapi.inc
function TCarbonWidgetSet.GetDeviceCaps(DC: HDC; Index: Integer): Integer;
begin
  Result := 0;

  {$IFDEF VerboseWinAPI}
    DebugLn('TCarbonWidgetSet.GetDeviceCaps DC: ' + DbgS(DC) + ' Index: ' + DbgS(Index));
  {$ENDIF}
 
  if not CheckDC(DC, 'GetDeviceCaps') then Exit;

  case Index of
  LOGPIXELSX,
  LOGPIXELSY:
    // logical is allways 72 dpi, although physical can differ
    Result := 72; // TODO: test scaling and magnification {Hardcoded value? I changed 72 to 96 and now It works how I searched for (read above and see below)}
  BITSPIXEL:  Result := CGDisplayBitsPerPixel(CGMainDisplayID);
  else
    DebugLn('TCarbonWidgetSet.GetDeviceCaps TODO Index: ' + DbgS(Index));
  end;
 
  {$IFDEF VerboseWinAPI}
    DebugLn('TCarbonWidgetSet.GetDeviceCaps Result: ' + DbgS(Result));
  {$ENDIF}
end;

I tested the Form.PixelsPerInch behaviour on Lazarus and Delphi and it is identical:
the .lfm and .dfm PixelsPerInch property is not meaningful - in the Object Inspector PixelsPerInch is equal to the OS DPI value (hardcoded? for Carbon widgetset (see above)).

When I changed the hardcoded value from 72 to 96 and created dynamically TLabel control assigning its Font to TFontDialog and printing TLabel.Font.Size and TLabel.Font.Height (for Times New Roman they are 12 and -16), BUT TFontDialog is showing "Size" = 16?

Please, comment my observations!

[cobata]

By using:

!.)
ScreenInfo.PixelsPerInchX:=96;
ScreenInfo.PixelsPerInchY:=96;

2.)
StringReplace(Memo.Text,sLineBreak+sLineBreak,sLineBreak,[rfReplaceAll]);

The problems were workarounded.
Done.

[AlexTP]

I think this 72 is not Okay. devs, pls change to 96.
Mac users write-

>>Aha! Looking with the correct phrase, "os x dpi", I get lots of hits. As expected, the general answer is no, the Mac OS still does not have a global DPI setting. It's all application independent. Each app does whatever it does and is unlikely to be the same as another app. So trying to find a magic point size that will always be xxx pixels tall would be a lesson in frustration.

https://discussions.apple.com/thread/5153667?start=0&tstart=0