>> And that from the first case?
 >
 > That's
 >
 > posframe.el:
 >    840 (defun posframe--fit-frame-to-buffer (posframe max-height min-height max-width min-width only)
 >    841   "POSFRAME version of function `fit-frame-to-buffer'.
 >    842 Arguments HEIGHT, MAX-HEIGHT, MIN-HEIGHT, WIDTH, MAX-WIDTH,
 >    843 MIN-WIDTH and ONLY are similar function `fit-frame-to-buffer''s."
 >    844   ;; This only has effect if the user set the latter var to `hide'.
 >    845   (let ((x-gtk-resize-child-frames posframe-gtk-resize-child-frames))
 >    846     ;; More info: Don't skip empty lines when fitting mini frame to buffer (Bug#44080)
 >    847     ;; http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e0de9f3295b4c46cb7198ec0b9634809d7b7a36d
 >    848     (if (functionp 'fit-frame-to-buffer-1)
 >    849         (fit-frame-to-buffer-1
 >    850          posframe max-height min-height max-width min-width only nil nil)
 >    851       (fit-frame-to-buffer
 >    852        posframe max-height min-height max-width min-width only))))

This doesn't explain the 199 vs 216 dichotomy yet.

 > And after some digging, I found several bindings for
 > frame-resize-pixel-wise, for example in posframe-show which is in the
 > backtrace.
 >
 > posframe.el:
 >    419                               (window-tab-line-height)
 >    420                             0))
 >    421          (mouse-position (cdr (mouse-pixel-position)))
 >    422          (frame-resize-pixelwise t)
 >    423          posframe)
 >
 > If I understand correctly what you write further down, this should not
 > be done, right? (Feng Shu <tumashu@163.com> added to CC, the posframe
 > author).

It might work if the frame is short-lived enough.  The problem with it
is that subsequent operations on that frame will immediately undo the
pixelwise effect unless they again bind 'frame-resize-pixelwise'.

 > Si I guess that explains that difference.

You would have to always report the value of 'frame-resize-pixelwise'
too when you report the values calculated by 'fit-frame-to-buffer'.

 > If you express it that way, I almost understand what it does :-).

Users should always set 'frame-resize-pixelwise' to t unless they rely
on two effects provided by window managers:

- When you drag a frame border with the mouse a pixelwise frame grows or
   shrinks by one pixel.  A non-pixelwise frame can grow or shrink by a
   line and/or column only.

- With some WMs when you drag a frame border with the mouse you get some
   feedback about the current size of the frame in some sort of a window
   on top of it.  See the attached resize.png with the (84x36) text in
   the center of the frame - that's how xfwm displays that information
   here.

Non-pixelwise frames behave like terminal windows - they cannot be
maximized orderly and do not play well with tiling WMs.  And since we
never fixed size hints to work orderly with decorations, frames cannot
be fit well to the sizes of their buffers.

 > So, if
 > my WM is not ever rounding down, I should set it to t? Might be a good
 > default for macOS...

I would set it regardless of whether my WM rounds down or not.

martin