bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames


From: Eli Zaretskii
Subject: bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized
Date: Thu, 08 Mar 2018 21:15:37 +0200

> Date: Wed, 7 Mar 2018 20:26:03 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com
> 
> updateFrameSize in nsterm.m calls SET_FRAME_GARBAGED, which appears to
> just flag the frame for clearing.
> 
> My assumption was that redisplay first checks if the frame is garbaged
> and if so clears it, then redraws the contents of the frame.
> 
> I put the calls to NS(En|Dis)ableScreenUpdates at the start and end of
> redisplay_internal:
> 
> modified   src/xdisp.c
> @@ -13868,7 +13868,7 @@ redisplay_internal (void)
>    redisplaying_p = true;
>    block_buffer_flips ();
>    specbind (Qinhibit_free_realized_faces, Qnil);
> -
> +  ns_disable_screen_updates ();
>    /* Record this function, so it appears on the profiler's backtraces.  */
>    record_in_backtrace (Qredisplay_internal_xC_functionx, 0, 0);
>  
> @@ -14602,7 +14602,7 @@ redisplay_internal (void)
>  #endif
>    if (interrupt_input && interrupts_deferred)
>      request_sigio ();
> -
> +  ns_enable_screen_updates ();
>    unbind_to (count, Qnil);
>    RESUME_POLLING;
>  }
> 
> I realise this isn’t robust, but I was just testing it out.
> 
> I imagine my failure here is that ns_clear_frame isn’t called from
> redisplay at all, but somewhere else.

I believe it is called from clear_frame, which is called by
redraw_frame, which in turn is called by redraw_garbaged_frames.

The call to ns_enable_screen_updates is too late, I think: you must
enable screen updates before redisplay_internal calls update_frame,
because that's where we actually draw stuff on the screen.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]