Resizing Window with Non-native title bar causes flicker in OpenGL app

gui
opengl

#1

I want to use the Juce title bar for my application but when we resize the app we get a strange flickering in the application content.

Our app is made of different components as well as an OpenGL component. I have noticed that the JUCE demo app has the same issue when resizing with the OpenGL content in view and the non-native title bar (in windows), and this doesn’t happen when you use the native title bar however!

EDIT: Its worth adding that its only the other juce components that flicker, not my OpenGL context. I have a toolbar, treeview and properties panel in seperate components and they are what are experiencing the flicker. (This is the same behaviour as the juce demo)

Any help would be much appreciated.

Thanks


Open GL and Native Title Bar
#2

IIRC this happens with the non-native title bar and the software renderer too!


#3

When you have some kinds of embedded heavyweight window like GL, sometimes a bit of flicker is unavoidable because it’s the OS windows themselves that lag in updating their position.

For us to help, some example code to reproduce the same thing you’re getting would at least give us somewhere to start.


#4

Hi Jules,

This issue is specific to when using the non-native titlebar though. I can potentially put together an example but this behavior is present in the Juce Demo (see link here) so can we not use this as .

Just like in our app, the flicker is happening to the non openGL components, the side menu and the titlebar.

Thanks
Matt


#5

Well, the difference is just that with a native title bar, Windows is in charge of resizing it, and it goes into an OS-level special handling thing. My guess is that it forces repaints to be flushed through while the user is dragging. With a non-native titlebar, it’s JUCE code that’s getting the mouse-drag events and changing the window bounds, so Windows doesn’t know that a drag operation is going on. In that case, the schedule at which the Window gets repainted is entirely up to the OS, I don’t think there’s anything we can do to make it behave differently.


#6

One of my engineers has been looking at this today, and hes found the following change has made a big improvement.

JUCE\modules\juce_gui_basics\native\juce_win32_Windowing.cpp

Comment out “if” statements under WM_NCPAINT handler (line 3005):

    case WM_NCPAINT:
        //if (wParam != 1) // (1 = a repaint of the entire NC region)
            handlePaintMessage(); // this must be done, even with native titlebars, or there are rendering artifacts.

        if (hasTitleBar())
            break; // let the DefWindowProc handle drawing the frame.

        return 0;

This non client paint was only ever getting into this handlePaintMesage() on a window move or maximize, not for a resize. Still not perfect and has the occasional flicker but noticeably better.

Can you comment on any negative impact that change might have?

Thanks
Matt


#7

@jules any thoughts on this?


#8

Well, I’m a bit reluctant to change something like that… I remember that whole NC painting stuff being very hard to get working smoothly, and doing this would force a lot more paint callbacks to happen, which could have other performance impacts when resizing windows without any GL…

However, when I wrote it, I was using Windows XP, so the underlying system is very different nowadays! if @ed95 can give it a sanity-check to make sure it doesn’t break any other situations then we should consider it…


#9

I’ll take a look


#10

OK, I couldn’t see any immediate issues or artefacts when removing this check so I’ve pushed it to develop.


#11

Yay, flicker gone!


#12

Hi,

It seems the problem is back, unfortunately.

I am on Win 10 using JUCE 5.3.2 and it flickers, when using the GL Renderer on a native title bar:
https://www.youtube.com/watch?v=QC-HCSGfTu4

I have attached a very simple test application, which causes this behaviour for me.

Main.cpp (2.4 KB)
MainComponent.h (862 Bytes)