bug#16976: 24.3.50; Flickering during frame creation for the NS-port with toolbar-mode enabled

["Jan D." <jan.h.d@swipnet.se>]

Hello.

Eli Zaretskii skrev 2014-03-29 18:07:
>> Date: Sat, 29 Mar 2014 17:28:42 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: konrad.podczeck@univie.ac.at, 16976@debbugs.gnu.org
>>
>> Eli Zaretskii skrev 2014-03-29 14:22:
>>>> Date: Sat, 29 Mar 2014 14:16:04 +0100
>>>> From: Jan Djärv <jan.h.d@swipnet.se>
>>>> CC: konrad.podczeck@univie.ac.at, 16976@debbugs.gnu.org
>>>>
>>>> I made SET_FRAME_GARBAGED a no-op, it still does a double redraw.
>>>
>>> Do you see 2 consecutive calls to update_window_tree?
>>>
>>
>> Well, it is difficult to tell as this function is called on mouse
>> movement and on every key stroke and on every blink of the cursor.
>> But turning off blink cursor, and testing with and without toolbar gives
>> 3 calls.
>
> Maybe I'm missing something here, so let me take a step back.  You
> said earlier that you see the frame cleared and redrawn.  I'm asking
> if you can trace this clearing and redrawing to any of the calls to
> update_frame or update_window_tree.
>

It seems the clearing is done because of an expose.
If we don't have a toolbar, NS thinks the frame is up to date when the 
event loop is entered after the first redisplay is done.

But if we have a toolbar NS thinks the frame is out of date and needs 
redrawing, thus sending an expose event (well, drawRect in NS speek) 
that does not happen without the toolbar.  So the clearing is already 
done when Emacs code is entered.

I don't know why we did not get this expose before, but much has 
happened, i.e. pixelwise resizing, event loop changes and more.

Maybe the generic code changed, because update_frame_tool_bar is called 
four times when a new frame is created.  NS does not have an 
"up-to-date" check on the toolbar, so it just recreates it.  This may be 
the cause.

	Jan D.