Hi On Wed, Mar 9, 2022 at 1:32 PM Akihiko Odaki <akihiko.od...@gmail.com> wrote:
> On 2022/03/09 18:26, Gerd Hoffmann wrote: > > Hi, > > > >> dpy_gfx_switch and dpy_gfx_update need to be called to finish the > >> initialization or switching of the non-OpenGL display. However, the > proposed > >> patch only calls dpy_gfx_switch. > >> > >> vnc actually does not need dpy_gfx_update because the vnc > implementation of > >> dpy_gfx_switch implicitly does the work for dpy_gfx_update, but the > model of > >> ui/console expects the two of dpy_gfx_switch and dpy_gfx_update is > separated > >> and only calling dpy_gfx_switch violates the model. dpy_gfx_update used > to > >> be called even in such a case before and it is a regression. > > > > Well, no, the ->dpy_gfx_switch() callback is supposed to do everything > > needed to bring the new surface to the screen. vnc isn't alone here, > > gtk for example does the same (see gd_switch()). > > > If dpy_gfx_switch() implies a full dpy_gfx_update(), then we would need another callback to just set the new surface. This would avoid intermediary and useless switches to 2d/surface when the scanout is GL. For consistency, we should also declare that gl_scanout_texture and gl_scanout_dmabuf imply full update as well. > > Yes, typically this is roughly the same an explicit dpy_gfx_update call > > would do. So this could be changed if it helps making the opengl code > > paths less confusing, but that should be a separate patch series and > > separate discussion. > > > > take care, > > Gerd > > > > Then ui/cocoa is probably wrong. I don't think it does the update when > dpy_gfx_switch is called. > > Please tell me if you think dpy_gfx_switch shouldn't do the implicit > update in the future. I'll write a patch to do the update in cocoa's > dpy_gfx_switch implementation otherwise. > > Can we ack this series first and iterate on top? It solves a number of issues already and is a better starting point. thanks -- Marc-André Lureau
