Forum > Carbon

Retina display and Carbon interface?

<< < (2/2)

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

Navigation

[0] Message Index

[*] Previous page