bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics <rudalics@gmx.at>]

 > Unfortunately, that did not work at all.  It made a big mess, in
 > all Emacs versions.  For one thing, each shrinking/enlargement
 > magnified the scale of zoom out/in over the previous one.
 >
 > I.e., each shrinking/enlargement was greater than the
 > enlargement/shrinking that immediately preceded it (not just
 > greater than the last shrinking/enlargement).

Which also demonstrates how fragile your code is.  You maybe rely on
some undocumented behavior, namely that setting the font size can set
the scrollbar width too, despite of the fact that you explicitly set the
scrollbar width to some specific value before.  And your code might
easily fail with toolkits that want to handle the scrollbar width
themselves.

The trap your code fell into can be roughly described as follows:

(1) You ask for changing the pixel size of a frame by setting the font
     size.  Emacs passes the request on to the window manager but on
     Windows it does _not_ store the new pixel size of the frame.

(2) You ask for changing the pixel size of a frame by setting the
     scrollbar width.

Now before my changes, (2) asked the window manager to change the pixel
size of the frame based on its line/column sizes multiplied by the
default font sizes.  After my changes, (2) asks to change the pixel size
of the frame directly from the previously calculated pixel sizes.
However, since on Windows (1) does not record the change of the pixel
size caused by setting the font size, the request in (2) will be based
on the pixel size of the frame before (1) was issued.

I don't know how to fix this properly.  IIUC Emacs cannot wait until
Windows passes the new sizes back to it in (1) just as it does on other
systems.  The sit-for I proposed earlier could work around this.  If
OTOH I restore the calculation for (2) to use the line/column values,
people who want to change the scrollbar width exactly by pixels are
lost.

martin