NEWT blinking on macOS when resizing

I'm using macOS Mojave 10.5.2, with jogl 2.3.2.

When resizing the window, it shows blinks with window background color (gray) and game graphics.

Not sure whether this is fixed in 2.4.0. Thanks.

Btw, using AWT/Swing with GLCanvas and VSync enabled is laggy on macOS as well, while NEWT is smooth like butter.

And the TextRenderer seems to render blurry text on HiDPI screens.

On 12/26/19 4:32 AM, xor [via jogamp] wrote:
> I'm using macOS Mojave 10.5.2, with jogl 2.3.2.
>
> When resizing the window, it shows blinks with window background color (gray)
> and game graphics.
>
> Not sure whether this is fixed in 2.4.0. Thanks.

Thank you for testing.

Probably not fixed in 2.4.0, but I will check its quality.
Quite a few changes were made in the MacOS code path.

Currently only NEWT has a 'pause animation'
for certain operations when using an AnimatorControl.
But even on X11 NEWT resizing flickers,
as we don't stop rendering in general.

On MacOS using AWT the situation is a little bit more complex,
as OpenJDK uses offscreen compositing in a fancy way,
which does not really allow us to control the FBO.
From memory we even have to issue a compositing animator
to achieve rendering to VSYNC - that explains that issue as well.
Bottom line: On MacOS using AWT is no more onscreen direct rendering.
Only NewtCanvasAWT guarantees direct onscreen rendering for all platforms.

In don't know which TextRenderer you are referring to.

I only support the Graph based text rendering from here on,
others are welcome to refactor the old AWT based text renderer
to make it AWT agnostic.

Thanks for the detailed explanation! This explains most of my test results.

Currently I’m testing NEWTCanvasAWT on mac, it works much better than GLCanvas, however it is still not as smooth as NEWT.

All my tests are done with single rendering context, and the testing workload has only a few textures, so I’m sure the time to render a frame is not a problem. But it’s still not smooth on combinations other than pure NEWT.

Update:

On mac:

The NEWT version is smooth almost all of the time;

However the NEWTCanavsAWT is smooth for a period of time, then experiences some frequent “shake” for a period of time, then repeat.

The GLCanvas version experiences random “shakes” almost all the time.

Btw, currently NEWTCanvasAWT needs some hack to work on mac.
Or one most resize the window for content to be seen (it shows black otherwise) .

My hack is to increase window size by 1, then decrease it.

I found a way to prevent that blink.

When resizing window, pause the Animator. However there isn't an event called windowResizeFinished, so there isn't a good time to restore that.

So this bug is related to the implementation of Animator which gets higher priority than resize so the window isn't able to respond in time.

Update: actually once animator is resumed, the window will only get repainted when animator triggers display.

When animator is resumed and window is resized, the window will remain default color until animator triggers display.

On 1/1/20 7:46 AM, xor [via jogamp] wrote:
> I found a way to prevent that blink.
>
> When resizing window, pause the Animator. However there isn't an event called
> windowResizeFinished, so there isn't a good time to restore that.
That is a problem.

One potential solution for some OS (MacOS AFAIK)
is not to do a live-resize: Pause animation and all display calls,
while using a background image during resize.
Here they usually use a time to define 'end of resize',
after pointer release.

>
> So this bug is related to the implementation of Animator which gets higher
> priority than resize so the window isn't able to respond in time.
Resize flickering is not really a bug, but nice to have not :)
Interesting description of the potential culprit from you here.

You mean the resize's 'display' fights animator's 'display' call?

Doesn't flickering usually happen w/ broken vsync, regardless who renders?
Note that our display calls are thread safe, i.e. blocking each other.

If you really like to resolve this issue (see above re non live-resize),
I give you a bugzilla account and please also consider X11 besides MacOS.

~Sven

See Bug 1361 <https://jogamp.org/bugzilla/show_bug.cgi?id=1361>,
which we may like to tackle as well here.

On 1/1/20 4:03 PM, Sven Gothel [via jogamp] wrote:
> If you really like to resolve this issue (see above re non live-resize),
> I give you a bugzilla account and please also consider X11 besides MacOS.
>

Thanks for taking a look at this “bug”.

I think the pausing while resizing is the best trade off giving current conditions.

However there are two technical difficulties,

yes we could define pointer press as resize begin, and pointer release as resize end, but currently there’s no way in NEWT’s event to know that.

And, when VSync is on, it seems that when the first resize event arrives, the rendering context is still owned by the thread blocking on swap buffers, so even animation is paused afterwards, it will experience a short flickering during the first resize event.

I’ve dig into jogl swap buffers implementation on macOS, it seems that VSync is disabled deliberately for 10 frames when resizing, maybe flickering is a side effect.

My experiments shows that the flickering is actually when you don’t paint the window in time, and at which point macOS composers shows default color. But that time may happen after swap buffers, making previous VSync’ed paint in vain.

Just guess.

On 1/1/20 6:20 PM, xor [via jogamp] wrote:
> Thanks for taking a look at this “bug”.
Send me a PM please so I can create a bugzilla account for you.

>
> I think the pausing while resizing is the best trade off giving current
> conditions.
>
> However there are two technical difficulties,
>
> yes we could define pointer press as resize begin, and pointer release as
> resize end, but currently there’s no way in NEWT’s event to know that.
NEWT does know when a resize event comes from the system,
i.e. triggered by the WindowImpl's sizeChanged(..) callback.
Here we could test whether a pointer is pressed and kick-off the
animation timer.
Subsequent sizeChanged(..) callbacks could then reset the timer.

>
> And, when VSync is on, it seems that when the first resize event arrives, the
> rendering context is still owned by the thread blocking on swap buffers, so
> even animation is paused afterwards, it will experience a short flickering
> during the first resize event.
Yes.

On 1/1/20 6:30 PM, xor [via jogamp] wrote:
> I’ve dig into jogl swap buffers implementation on macOS, it seems that VSync
> is disabled deliberately for 10 frames when resizing, maybe flickering is a
> side effect.
>
> My experiments shows that the flickering is actually when you don’t paint the
> window in time, and at which point macOS composers shows default color. But
> that time may happen after swap buffers, making previous VSync’ed paint in vain.
>
> Just guess.

Makes very much sense, yes.

The MacOS code path for AWT FBO offscreen is probably the biggest PIA
within JOGL indeed.

If you are up to this task, let's make our dialog and findings
persistent via bugzilla (PM me) - copy all this here to a new
bug entry for MacOS, which is related to Bug 1361.

Then we can both tackle it, which I would prefer.

~Sven