On 10/02/12 18:55, Ilyes Gouta wrote: > 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())?
You are correct, blocking the dispatch thread is not really acceptable. We were aware of that issue and planned to fix that soon. -- Denis Oliver Kropp DirectFB integrated media GmbH _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
