I have a Qt application using OpenGL drawing with QGLWidget, on Mac OS.
On my MBP it works well, but when trying on a 30" screen, I noticed that there is a window size limit.
If I increase the window size beyond a certain limit, the QGLWidget's content disappears and only some greyish memory junk is visible.
I changed the code to only put a QGLWidget on the screen. The repaint event is setting the background black in each iteration.
The issue is still visible: when resizing the widget, the black surface disappears and gets replaced by the memory junk, when the size of the widget reaches a certain size.
Interesting facts:
When I decrease the window size, the GL surface comes back to live again
I have several other GL applications (not Qt) running in maximized window, so the issue is not with the OpenGL driver/video card
It seems that the area of the window (nr of pixels) matters, if I make the window very wide, it's height will be limited and vica versa, I if the windoe is maximized in height, the width must be small
I found that while instantiating the QGLWidget using QGLFormat(QGL::NoSampleBuffers) instead of QGLFormat(QGL::SampleBuffers) solves the issue.
Related
There is a Qt window, which hosts many widgets, among them is one QOpenGLWidget widget to plot waveform. This works well on almost all machines, but there is one strange case with a machine having an Intel OpenGL graphics version 3.3.0 - Build 21.20.164678.
This is the good behavior on almost all machines:
And this is the strange case, wherein title text goes beyond top border of the window, and to click a button, we have to offset mouse pointer above the rendered position of that button. Text is also a little bit blurry. This problem does not happen if I replace the OpenGL widget with another non-OpenGL widget:
Any suggestions to fix the issue?
Currently if I make a window in GTK3
For example 300x300
And I put a button at the bottom, right hand corner, I can not shrink my window
Size because this button is preventing me is there a function in gtk3 that can allow me to ignore all widgets, and resize to anything even 0x0
And this is the user doing this with the window resize, drag and click
And is there a way where I can set this resize limit myself, and not have this dependent on whats in my window
If you initially use set_size_request() to set the window to 300x300, then it won't shrink below that. To allow users to shrink below an initial value, use set_default_size(). I seem to have read that the minimum size of a widget is 1x1, which seems logical, as, at 0x0 you wouldn't be able to resize it anymore. If you want less than 1x1, you can use hide() and just hide the contents.
But if you have any widgets inside the window, then the minimum size is determined by the widgets! (Called the 'natural size')
To allow a window smaller that than the one determined by the widgets, you can maybe use a Gtk.ScrolledWindow.
Also, recall that the outer border is drawn by the window manager, NOT by Gtk. However, you can disable the outer border by using set_decorated(). Not that this may not work - depending if the window manager respects this (not Gtk's fault).
I want SDL window size to stay within working area (SPI_GETWORKAREA) of windows which excludes windows taskbar other panels.
The problem is that both SDL_CreateWindow and SDL_SetWindowSize set the client area of window, not the size including window borders. So when I set window size to fit on a small working area, the borders still go out of working area.
SDL_CreateWindow: Use this function to set the size of a window's client area.
Does SDL provide a way to set window size within working area? or how do I get border size of SDL window so that I can do that myself?
You don't even need WinAPI to do that.
The size of window borders can be determined by SDL_GetWindowBordersSize(), and the part of the display not occupied by taskbar should be returned by SDL_GetDisplayUsableBounds().
With these functions, maintaining a proper window position (and maybe size) should be easy.
The only way I know of (SDL 1.2) is to first create a small window (2x2 pixels) and then check the total window size using the Windows API (GetWindowPlacement). Based on this, you can calculate the parameters necessary to get the window size you are looking for, and finally resize the window (MoveWindow).
I hope someone has a better solution, because this is a very ugly workaround.
I've been working on an OpenGL-based application that runs directly on Win32. I've noticed an issue where when I resize the window, the drawing can't keep up around the edges. Here's a video of the issue in action. (Note the bottom-right and top-right corners of the window)
I am running the redraw function inside of my WM_SIZE event, but it still has a slight delay.
If there is a way to make it not have this visual artifacting - great! If not, how can I keep the window from updating its size until the controls have been drawn?
I've created a Direct3D 11 application that allows the window to be resized. I am drawing 2D content, and I want it to stay the same size regardless of what I do to the window, so e.g. shrinking the window from the lower-right corner should hide anything on the right or bottom, but leave anything in the upper-left stationary.
However, although I am resizing the back buffer in response to WM_SIZE as described in the documentation for IDXGISwapChain::ResizeBuffers, I still see the window contents stretch or squish for a few moments while resizing before it corrects itself. This makes the window contents appear to fluctuate up and down in size while I drag the window to its new size.
It turns out that when creating the swap chain, I left my DXGI_SWAP_CHAIN_DESC1's Scaling field zero-initialized, which turns out to be DXGI_SCALING_STRETCH. Switching to DXGI_SCALING_NONE fixed the problem (and reduced how often I needed to resize the back buffer).