On Mon, Dec 18, 2017 at 11:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> ​​
> > Date: Mon, 18 Dec 2017 08:26:23 +0100
> ​​
> > From: martin rudalics <rudalics@gmx.at>
> ​​
> > Cc: emacs-devel <emacs-devel@gnu.org>
> ​​
> >
> ​​
> >  > ​Please describe in detail what you see and what you think
> ​​
> >  > is wrong but update to 1.1 attached first.​
> ​​
> >
> ​​
> > Here on Windows XP I mostly see an incompletely drawn frame with the
> ​​
> > entire or parts of the toolbar missing, sometimes also a completely
> ​​
> > blank frame.  More or less what you described earlier in another thread.
>
​​
​

> ​​
>
> ​​
> Which is quite expected, since the frame is created by a separate
> ​​
> thread, and the display-until library doesn't give Emacs a chance to
> ​​
> create it before it calls 'redisplay' (which has nothing to redisplay,
> ​​
> as the frame is not official yet), and then immediately goes into the
> ​​
> sleep-for loop (which doesn't redisplay).  I think.
>

​If possible, shouldn't make-frame wait until the frame is
created and mapped to the display if the creation command
demands mapping?  I guess you could start editing properties
on ​an as yet unmapped frame but in the general case, wouldn't
a programmer want the frame and its constituent parts to
exist prior to moving on?

Since frame creation is done by a separate thread now,
are all following operations on the frame queued until the
whole frame is built or will they be lost if invoked during
this interim creation period.  For example, if I change an
item on the toolbar prior to full toolbar creation, what
happens?

How can an Elisp programmer be sure the frame creation has
finished without any reference to its creation thread?

Bob
​​