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

[Drew Adams]

>  > 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 are welcome to improve it or offer concrete suggestions - please do.

FWIW, it works fine, AFAIK, on all previous versions of Emacs, and on all
platforms I'm aware of.  I use it myself with Emacs 20-24 on MS Windows
and with Emacs 21.3 on GNU/Linux (KDE & GNOME).

> 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.

Why should asking to change the scroll-bar width constitute a request to
also change the pixel size of the frame?  Or did you mean only that
changing the scroll-bar width will change the frame width slightly?
The latter I could probably live with.

> 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.

Good to understand.  Thx.  Not sure what that means in terms of trying
to get my code to work properly with your new code (as well as with
prior Emacs code).  Concrete suggestions welcome.

> 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.

Are they necessarily lost, or is there some other way to accommodate both?

BTW, as far as you can tell, is it just the scroll bar that is the problem
(wrt my code)?