Hi Andi, This is about the commit 2cc44cc, where it changes wm_update_cursor()'s dfb_layer_region_flip_update() to take DSFLIP_WAITFORSYNC instead of a DSFLIP_NONE.
The callstack when an input event is dispatched via dfb_input_dispatch() is as follow: _dfb_windowstack_inputdevice_listener(); dfb_wm_process_input(); wm_local->funcs->ProcessInput() -> wm_process_input(); flush_motion(); perform_motion(); dfb_windowstack_cursor_warp(); dfb_wm_update_cursor(); wm_local->funcs->UpdateCursor() -> wm_update_cursor(); Then within wm_update_cursor(): Line 4385: case DLBM_BACKVIDEO: Line 4387: dfb_layer_region_flip_update( primary, NULL, DSFLIP_WAITFORSYNC ); Wouldn't DSFLIP_WAITFORSYNC cause input handling to delayed since wm_update_cursor() is called within the context of _dfb_windowstack_inputdevice_listener()? DSFLIP_WAITFORSYNC will block for a VSYNC period before returning and that's a interval where the input events won't be consumed, leading to a mouse cursor motion lag (DirectFB single-mode, default wm)? Would it make sense to perform the dfb_layer_region_flip_update( primary, NULL, DSFLIP_WAITFORSYNC ) in the context of another thread, besides 'Fusion Dispatch' (which serves _dfb_windowstack_inputdevice_listener())? -Ilyes _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
