I want to create an SDL window in an existing app. The problem I encounter is that at startup, after the SDL_SetVideoMode call, a black window pops up until the remaining of my application is initialized. This is ugly and I was wondering if there was a function which controls the hide/show of this window.
There doesn't seem to be such a function in SDL, however if there were, I'd likely make you see a window pop up and disappear right away, which you may also consider ugly. You'd better display some "Loading..." message in a window, or postpone SDL_SetVideoMode call to the point when your application is fully initialized. The former is better, as the user will know that he has actually launched an application and won't try to run it multiple times.
Related
I have a problem handling GLFW poll events. As far as I know, all user input events are handled via callbacks or via constantly checking keyboard / mouse states. The latter is not so efficient an can even result in missing some input (e. g. when button pressed and then released between checking state). What is more, some events like window resizing cannot be handled without callbacks.
So, the problem is that whenever user starts resizing window (presses mouse button but doesn't move mouse), the app seems to freeze. This is, assuming resize callback is enabled and defined validly (even when copied right from GLFW API). And the problem is not that window doesn't redraw. Redraw on callback can be done with creating and calling own render() function in callback function.
The actual problem is that even when I handle resize event properly and redraw on callback, there is still some lag. This lag is after mouse press on decorated window border and when mouse is not moving. Here's a demonstration (button click is highlighted green):
Sorry for messed up GIF. All callbacks listed in GLFW API are enabled and handled (window-, input-, joystick- and monitor-callbacks) and redraw is called in each one. It seems that I'm missing some of the callbacks or GLFW just works like that.
According to this answer, this can't be done without threading:
That only works when the user moves the mouse while holding - just holding left-click on the resize window part still stalls. To fix that, you need to render in a separate thread in addition to this. (No, you can't do that without threading. Sorry, this is how GLFW works, no one except them can change it.)
So, the questions are:
How can I fix this issue without threading? If I can't, I guess I can emulate resizing with different cursors shapes and resizing zones or smth like that...
If this is still impossible to solve in GLFW, do other GLFW alternatives have this issue?
Are there any problems with GLFW similar to this one?
GLFW is not at fault here. It's how the operating system handles certain user input events like mouse down on the decorator resize handles of a window or moving the whole window.
See this answer for a more elaborate detail: Win32: My Application freezes while the user resizes the window
GLFW uses the standard Windows PeekMessage -> TranslateMessage/DispatchMessage loop which you will find in any GUI Windows application. This will get invoked when you call glfwPollEvents() and it processes all Window event messages that the OS has accumulated so far for all windows in this process. After all messages so far have been processed, the call to glfwPollEvents() will return and will allow your own window/game loop to continue.
What happens is that once the user clicks down the window decoration's resize handles, effectively the call to glfwPollEvents() will block within the OS itself in order for the OS / window-manager to intercept the mouse and keyboard messages to do its window resizing/reshaping thing.
I'm afraid that even though Windows will inform the process about the start of a window resize or move action (after which the OS will have control of the window message processing) and GLFW already handling these events internally, right now GLFW will not notify the client application about this. It would be possible though for GLFW to provide an appropriate event callback to the application, so that the application can start a timer or thread only for as long as the window resize/move action happens (as is also mentioned in the linked other Stackoverflow answer).
So, the only thing that you can do in order to keep rendering while the user holds onto the resize handles or while the user moves the window around, is to render in a separate thread.
I'm asking this question ahead of time, since I haven't gotten around to attempting an actual, real implementation yet. Win32 (C++) is turning out to be a colossal pain to program. But, my question is this:
I want to make my application's window become fully transparent with a dotted perimeter when resizing the window. How would I accomplish this? Think of what happens in Windows 3/3.1 (I believe it was this version) when resizing a window. Everything goes transparent, with a dotted-outline where the mouse is moving, then it repaints the entire contents. That's what I'm trying to achieve.
A while ago, I tried handling the WM_(ENTER/EXIT)SIZEMOVE messages and make use of SetWindowLong() to set the WS_EX_TRANSPARENT extended style, but my window became (indefinitely) pass-through, and when the window's focus was killed, it could never again regain focus.
Do I need to handle other messages like WM_NCLBUTTON(DOWN/UP)? I have a boolean flag to tell me when to halt drawing during resizing, and the logic for determining when I'm resizing works perfectly, but I cannot get the visuals to work. I'm not sure which parts of the Win32 API to actually use. I've done some research, and uxtheme.lib/.h seems promising, but I'm not sure how that would work with WM_NCPAINT, which I have been using with (some) luck.
EDIT
I need to clarify something, in case anyone was confused or unsure of what I meant. What I meant by the Windows 3.1/3 resizing scenario is that once WM_ENTERSIZEMOVE has occurred, the window (controls, caption, frame) should be made entirely invisible, and the window's nonclient-region's perimeter should display a dotted-outline of sorts. Then, only until the resize has been finished, when WM_EXITSIZEMOVE has occurred should the entire window (controls, caption, frame) be fully redrawn, updated, and returned to its normal, functional state. Sorry for any miscommunication!
I found the answer... After so long, finally found it. Here's where I found it! http://www.catch22.net/tuts/win32/docking-toolbars-part-2# - Hope it helps anyone else possibly in my shoes!
And it turns out that the solution was rather simple. In fact, the core concept of what is explained is near-completely what I was thinking, yet I just had no idea how to implement it. The solution involves overriding the default WM_NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP (specifically when initiating a window movement) messages, and drawing a patterned rectangle which follows the position of the cursor. Then, afterwards, calling SetWindowPos or some other similar function to relocate the window.
Basically, block Windows from attempting to display anything graphics related until the resizing has been finished. Then, and only then, make Windows move the entire window in one huge, foul swoop.
Based on Remy's comment, there is a global option and corresponding registry setting for this, so perhaps try setting the registry setting when the move starts and restoring it when the move finishes.
Unfortunately this doesn't work as Windows appears only to pick up the setting on restart, broadcasting WM_SETTINGCHANGE also doesn't trigger it, which is a pity as doing something yourself that the OS already has an implementation of do is rather a poor state of affairs.
I'm trying to create a simple Paint application using MFC. So everything working good and as expected. I have just one issue with resising, in fact when i re-size my window or minimizing it everything disappear and I got blank page. I found that this's caused by the OnDraw function, but I can't find how to deal with that issue.
The purpose of the OnDraw function is to recreate the drawing after the window has been resized/uncovered/unminimized. Your OnDraw function must be able to draw everything at any time. So the event handlers like OnLButtonUp should set variables that can be used by OnDraw. Then the event handlers can call Invalidate to cause a new OnDraw.
I have a problem with a progress bar that is implemented through adding a D2D object in MFC library.
I set up a message map to my function that keeps redrawing the progress bar based on some calculations:
BEGIN_MESSAGE_MAP(CProgressControl, CStatic)
ON_WM_PAINT()
ON_REGISTERED_MESSAGE(AFX_WM_DRAW2D, &CProgressControl::OnDraw2D)
END_MESSAGE_MAP()
My problem is that when the user locks out of the computer and the screen is asleep my drawing function does not seem to be called. It seems that the D2D notification message AFX_WM_DRAW2D is never sent to redraw when the screen is asleep.
I have tried to search for information on this online but did not find anything good about what might happen differently when the screen is asleep. I would appreciate any insight anyone might have on this.
Seems to me like this could be a normal behavior. Do you get any messages when your app is minimized or the computer is locked? I suspect that not.
Anyways, why should this bother you? Obviously your progress bar is invisible at the time, so why bother with the panting? You should be happy - Windows has an optimization for your program.
However if you do anything else besides painting in the painting messages, then I'd advise moving it elsewhere, as it is not that right place for it anyway. Paint message handlers should ONLY contain paint logic, and be prepared to be called at any time (or not at all).
Search the MFC sources for AFX_WM_DRAW2D and you'll see in wincore.cpp that the message is sent from a method called CWnd::DoD2DPaint() inbetween the render target's BeginDraw and EndDraw calls.
Therefore call DoD2DPaint to force a repaint. I did this on the sample CMFCD2DWalkthroughView (http://msdn.microsoft.com/en-us/library/gg482848.aspx) in the OnSize method to ensure that the gradient is updated and painted when the window is resized instead of the size/paint being out of sync.
Is there a good way for preventing a window from being moved in gtkmm?
At first I tried to do this by overloading on_configure_event (forcibly move window to fixed position), but this caused some strange graphical glitches and huge slowdowns during a resize of window.
Window position is usually a responsibility of the Window Manager, not of the application. You are fighting the system, and hence the glitches.
My advice is: just don't do it. The user should be able to move the window.
If you really need this, the best thing is to tell the Window Manager not to manage your window, and then do the managing tasks you still need yourself (resizing the window, for example).
For details, see the function gtk_window_set_decorated() and the GTK_WINDOW_POPUP argument to gtk_window_new().