I'm not sure if anyone mentioned this yet, but it appears Mir's default behaviour is to immediately draw a frame on compositor (re)start (for non-nested servers only, like USC).
It's the last parameter here:
return std::make_shared<mc::MultiThreadedCompositor>( the_display(), the_scene(), the_display_buffer_compositor_factory(), the_compositor_report(), !the_options()->is_set(options::host_socket_opt)); <=== bool compose_on_start
I'm wondering if we've got that backwards. What we want to see on resume is a new frame from the nested server propagate through. So that statement should probably just be inverted:
the_options()->is_set(options::host_socket_opt));
Thus on resume, the first frame comes from the nested server. Although we'd also want the same in the case of a single-server system.
I'm not sure if anyone mentioned this yet, but it appears Mir's default behaviour is to immediately draw a frame on compositor (re)start (for non-nested servers only, like USC).
It's the last parameter here: shared< mc::MultiThread edCompositor> (
the_display( ),
the_scene( ),
the_display_ buffer_ compositor_ factory( ),
the_composito r_report( ),
!the_ options( )->is_set( options: :host_socket_ opt)); <=== bool compose_on_start
return std::make_
I'm wondering if we've got that backwards. What we want to see on resume is a new frame from the nested server propagate through. So that statement should probably just be inverted:
the_ options( )->is_set( options: :host_socket_ opt));
Thus on resume, the first frame comes from the nested server. Although we'd also want the same in the case of a single-server system.