OpenGL with SRgb color space no longer works in Qt6.4+ - qwidget

I have an OpenGL application with a QWidget-based (no QtQuick/QML) Qt UI that I ported from Qt5 to Qt6. Most of it works fine, except that with Qt 6.4 and the Qt 6.5 beta (Qt up to 6.3 works fine!), the QSurfaceFormat color space setting no longer has an effect. I could not find any changes in the change log that should affect this. The only OpenGL-related change mentioned is to the RHI which shouldn't matter since I don't use QtQuick/QML.
In my main, before creating the QApplication instance I set up my default surface format and the Qt::AA_UseDesktopOpenGL attribute as follows:
auto surfaceFormat = QSurfaceFormat::defaultFormat();
surfaceFormat.setVersion(3, 3);
surfaceFormat.setProfile(QSurfaceFormat::CoreProfile);
surfaceFormat.setOption(QSurfaceFormat::DebugContext);
surfaceFormat.setColorSpace(QColorSpace::NamedColorSpace::SRgb);
surfaceFormat.setSamples(4);
QSurfaceFormat::setDefaultFormat(surfaceFormat);
QApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
QApplication app(argc, argv);
In the constructor of my QOpenGLWidget-derived widget, I set a compatible texture format and the update mode:
setTextureFormat(GL_SRGB8_ALPHA8);
setUpdateBehavior(QOpenGLWidget::NoPartialUpdate);
In initializeGL I set up a QOpenGLDebugLogger and load my OpenGL functions using glad Using QOpenGLFunctions is not an option as that would imply making the rendering code Qt-dependent and/or require significant changes. I also tried outputting the name of the color space reported by the widget's surface format via qDebug() and it is "SRgb" as expected.
At the beginning of paintGL I ensure GL_FRAMEBUFFER_SRGB is enabled before drawing using glEnable(GL_FRAMEBUFFER_SRGB).
In summary, it works in Qt 5.13 to Qt 6.3.2, but stops working with Qt 6.4 (the 6.5 beta adds another bug where menus have a black background but it's a beta). I am not getting any relevant OpenGL debugger messages, just a lone performance warning due to a re-compiled shader. Am I doing something wrong that just happens to work on previous versions or is this a bug that none of the many Qt users have discovered over the course of more than one minor revision? Any ideas regarding resolutions / workarounds?

Related

Correct way to resize swapChain in DirectX12

I am attempting to port the DirectX12/XAML UWP template over to a C++-WinRT version... where EVERYTHING is done via C++-WinRT and I can turn off CX. I'm currently stuck on how to ResizeBuffers on the swapchain. Before resizing the buffers I have to release all the buffer references. In C++/CX ComPtr there is Reset() method to release reference of the renderTarget buffers, but in C++/winrt com_ptr no such Reset() method exists and if I set renderTarget to nullptr in order to release it, it throws an exception shown in the Screenshot below. And if I don't set the renderTarget to nullptr then exception is not thrown but the swapChain is also not resized.
Later I also tried it using the wrl::ComPtr and the Reset() method it is still throwing the same error. Does anyone know the correct way of resizing the swapChain in DirectX12?
Screenshot of the code and error
You can't use a "fail-fast" error handler like ThrowIfFailed for ResizeBuffers or Present. Both return meaningful failure codes at runtime you must handle.
Specifically both can return DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET and you need to handle it. In fact, in the UWP environment, you will see this happen at start up so you must handle it--some 'classic' Win32 desktop apps just ignore it and crash at weird times like when Windows Update updates a driver while the game is running.
For details on handling 'lost-device' (which is really 'device removed'), see DeviceResources .h / .cpp.
See also Microsoft Docs which is written for DirectX 11, but all the equivalent stuff has to happen for DirectX 12.

How do I change the appearance of my Xcode app?

I'm trying to create a dark mode for my application made in Xcode 8. My first though was to use Mojave's Dark Aqua, but I get many errors:
Unrecognized effect parameter type 10 encountered for effect type 1131375730. Skipping.
My next idea was to create my own .car file, using https://github.com/insidegui/AppearanceMaker. However, this did not change the background/window, even when I edited its Windows and Menus/Menu/Menu Background and its Colors/Window Background.
My third idea was to use El Capitan's Dark Theme (for the dark Menu and Dock, I'd assume). However, this changed the Aqua blue to a grey. Laaaaame.
What am I to do?
At the end of the day, Mojave's DarkAquaAppearance worked! I needed to set my NSWindow to the theme. (using yourNSWindow.appearance = [[NSAppearance alloc] initWithAppearanceNamed:#"DarkAquaAppearance" bundle:nil];, making sure that DarkAquaAppearance.car is in your "Supporting Files")
If you want to do the same, I have all the Mojave appearances in https://github.com/radzo73/Mojave-Appearances. It still will call errors about "Unrecognized effect parameter", but that's probably just the compressed assets, and I'm using an older system. ¯\_(ツ)_/¯
With (real) hope,
Conrad

How to supress Cytoscape.js warning for custom wheel sensitivity?

Since we updated to Cytoscape.js to version 3.3.2 we get the following warning:
You have set a custom wheel sensitivity.This will make your app zoom
unnaturally when using mainstream mice. You should change this value
from the default only if you can guarantee that all your users will
use the same hardware and OS configuration as your current machine.
As we intended the mouse wheel sensitivity to be that way, the warning is superfluous in our case. How can we suppress it?
cytoscape.warnings(false)
The docs say this about warnings:
Note that Cytoscape.js will print warning messages to the console to help programmers avoid mistakes. If you want to disable these messages, call cytoscape.warnings(false) to turn warnings off completely. You can turn them back on with cytoscape.warnings(true), and you can get the current state with cytoscape.warnings(). It is recommended that you leave warnings enabled at least for development builds of your app.

Use Qt 5 Wayland QPA plugin to set window transparency with wl_surface

I have three Qt 5 applications that work fine independently on the BeagleBone X-15 using the Qt 5 Wayland plugin on the TI SDK image.
When I launch them, they fill the whole screen so that the first app launched is covered by the second, and the second app is covered by the third.
How can I modify the transparency of the second and third app launched, so that I can see some of the view from the first app launched?
I tried modifying the window opacity with Qt’s setWindowOpacity, but the Wayland plugin says: “Window Opacity not supported by this Plugin.”
Qt 5 on Wayland page says:
Qt 5 is structured with the Lighthouse (or Qt Platform) Abstraction, which is the windowing system and device agnostic architecture. That means Qt can load in run-time different backend plugins for different window systems as desired. For instance, an application developed on Qt could be run using "-platform xcb" and "-platform wayland" for XCB or Wayland respectively (or set the QT_QPA_PLATFORM environment variable) and should have a similar behavior on both systems, without the need to recompile.
Qt abstraction exposes to applications developers two native resources of Wayland: wl_display and wl_surface. With those types, one could access Wayland internals to deal with special cases through the interface:
void *QPlatformNativeInterface::nativeResourceForWindow(const QByteArray &resource, QWindow *window)
Getting the display global handler is quite straightforward, as shown in the following example:
QPlatformNativeInterface *native =
QGuiApplication::platformNativeInterface();
struct wl_display *wl_dpy = (struct wl_display *)
native->nativeResourceForWindow("display", NULL);
and for wl_surface:
QPlatformNativeInterface *native =
QGuiApplication::platformNativeInterface();
struct wl_surface *surface = static_cast<struct wl_surface *>(
native->nativeResourceForWindow("surface", this->windowHandle()));
If I get the handle to this wl_surface, how can I change the transparency directly?

Set windows size of QuickLook Plugin

I'm building a QuickLook plugin. I want to change the width of the windows that pops up when user hits the spacebar.
I've read there are two keys in the info.plist file of the project where height and width are customisable. Even if I change those values I can't get the size of the preview windows to my desired one.
I don't know what else to try. Any idea?
Thanks!
Thought I'd dig a little on this. I have not tried any of the following suggestions, so nobody get their hopes up. I'll assume you're using the generator callback:
OSStatus (*GeneratePreviewForURL)(
void *thisInterface,
QLPreviewRequestRef preview,
CFURLRef url,
CFStringRef contentTypeUTI,
CFDictionaryRef options
);
Before anything else, you might manually check the options dictionary argument and verify that the kQLPreviewPropertyWidthKey and kQLPreviewPropertyHeightKey keys are indeed mapped to the desired CFNumber values.
Referring to each of these properties, the Apple QuickLook programming guide says:
Note that this property is a hint; Quick Look might set the width
automatically for some types of previews. The value must be
encapsulated in a CFNumber object.
(Edit: If your preview representation is flexible, you might try finding a preview type for which QuickLook honors your size hints, as per the statement above. Just a thought.)
Running nm on the QuickLook framework binary revealed some undocumented kQLPreviewProperty-- constants as well as the aforementioned width and height keys. One that caught my attention was kQLPreviewPropertyAutoSizeKey. Recalling Apple's statement about ignoring the hints to set the size automatically, this might be significant? Following the convention in QuickLook.framework/Headers/QLBase.h, you might try declaring
extern const CFStringRef kQLPreviewPropertyAutoSizeKey;
Then you could try associating a CFNumber 0 with that property key in the options dictionary. There are other undocumented keys of note, such as kQLPreviewPropertyAttributesKey.
Back to the Info.plist you mentioned, Apple says about those keys QLPreviewWidth and QLPreviewHeight:
This number gives Quick Look a hint for the width (in points) of
previews. It uses these values if the generator takes too long to
produce the preview. (emphasis added)
This is where someone makes the terrible suggestion of calling sleep() in your generator. But I'm perplexed as to why Apple would make following the size hints dependent on the generator latency. (?)
Edit: Also note the above statement says the Info.plist hints must be expressed in points (not pixels), a unit dependent on the user's screen resolution.
Recently I was developing a Quick Look Plugin myself which uses HTML+CSS and faced the same problem.
The solution for my was to test the plugin not within Xcode and qlmanage as the executable but instead to try the real .qlgenerator from my user library.
When invoking the generator from my user library, the Quick Look window was resized exactly the way I specified in the *-Info.plist.
I've run into the same problem, and may offer some clues: In my case I'm generating an image quick look preview for my custom file format. I initiate the preview context to draw my preview into using
CGContextRef QLPreviewRequestCreateContext(QLPreviewRequestRef preview, CGSize size, Boolean isBitmap, CFDictionaryRef properties);
The curious thing is that if I set isBitmap to true, quick look adjusts the preview panel size to the size specified for the context (up to a certain size at least). But if you set isBitmap to false, it seems to disregard the context size and instead always shows a full size preview panel with the vector graphics image scaled to cover the entire panel.
So, if you use a bitmap graphical preview context, it seems the preview panel will be set to the size of the context you specify. However, I haven't found any way to set the size of the panel when using a vector graphic preview context (which is what I want).