[Interface kit] Resizing tracker window flickers address bar

[idefix]

Not only the address bar flickers, but every element that moves or resizes: address bar, folder icon (upper-right corner), item count (lower-left corner) and yellow tab (if the window is too small to show the whole tab). Only the scrollbars (except for some 1 pixel lines), window borders and resize grip don't flicker.

[idefix]

Forgot to mention: the menu bar (if the window is too small to show the whole menu bar).

[diver]

Replying to idefix:

Not only the address bar flickers, but every element that moves or resizes: address bar, folder icon (upper-right corner), item count (lower-left corner) and yellow tab (if the window is too small to show the whole tab). Only the scrollbars (except for some 1 pixel lines), window borders and resize grip don't flicker.

That's right.

[diver]

Still here in hrev35141

[diver]

Still reproducible in VirtualBox with hrev38300.

[diver]

Qt also had this problem years ago but they fixed it ​http://blog.qt.io/blog/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

I also remember that SkyOS was flicker free due to window compoziting ​https://web.archive.org/web/20060813061351/http://www.skyos.org:80/?q=node/508

I wonder if buffered windows that stippi mentioned recently on IRC could fix this issue? Stippi?

[diver]

On the other hand not all widgets flicker during window resize, I wonder why is that.

[stippi]

Normal drawing updates in Haiku are actually flicker free. When windows are resized however, there are two mechanisms: The widgets get a new size, and are requested to draw. When the widget has a background color set, the app_server will pre-fill the exposed areas with that color. Widgets can set a transparent view color to prevent that from happening. In addition, some widgets request to be redrawn in full when they are resized. Perhaps the process could be more optimized to prevent flickering, but when it happens, it is due to these circumstances. The combination full update + non-transparent view color should be the one that leads to flickering.

[stippi]

... perhaps it is not yet clear why flickering actually happens. The crucial bit is how screen updates are synchronized. I think for normal drawing updates, the app_server will delay a screen update until the view is finished drawing, even when the view has a non-transparent view color and the app_server pre-fillied before drawing. During resizing, there is less synchronization and the app_server won't delay screen updates until all views in a window have actually finished drawing. Then it depends on how much the app_server has pre-filled and how much the view managed to draw when the screen update happens.

[X512]

Duplicate of #15548. Issue resolved with proposed fix.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed