I am developing a document based application for Mac OS X. It's a kind of media player, but instead of playing audio or video files it is supposed to open text-files containing meta-data specifying OpenGL animations. I would like to mimic Apples QuickTime X window style. This means, i have to do all the window drawings myself, because Cocoa has no appropriate window style.
There is one thing which gives me headaches: The rounded corners usually to be found on Mac OS X windows. I tried using the borderless window mask and working some CGS magic - there are some private Apple headers which allow window shaping, but they are of course undocumented. I was able to cut rectangular holes in my windows edges, but i couldn't figure out how Apple achieves rounded corners.
Creating a transparent window and drawing the frame myself does not work, because an OpenGL viewport is always rectangular, and the only way to change it is to turn on NSOpenGLCPSurfaceOpacity for alpha transparency and using the stencil buffer or shaders to cut out the edges, which seems like a hell of a lot of overhead.
If i put an OpenGLView into a standard Cocoa window with titlebar, the bottom edges are rounded. It seems this is happening at the NSThemeFrame stage of the view hierarchy. Any ideas how this is done?
Use a layer-backed view, and do your drawing in the CALayer on an invisible window. Layers include automatic handling of rounded corners and borders.
Background for CALayer is in the Core Animation Programming Guide. To create a layer for NSView, you need to call [view setWantsLayer:YES]. You would create a CAOpenGLLayer and assign it to the view using setLayer:.
See CALayerEssentials for sample code demonstrating how to use CAOpenGLLayer among other layer types.
Since Robs suggestion didn't work and no one else contributed to the discussion i settled on using the stencil buffer to crop the windows corners. I did this by creating a texture from the windows background and rendering it into the stencil buffer, discarding all transparent pixels. Looks fine, but is slow when resizing the window :/
Related
When resizing down in DirectX I noticed a flicker along the bottom/right edges.
If you fix the size of the swapchain (in red), and set the win32 background to green you will get the following on a resize down:
It appears that the window size lags behind the mouse position ("Drag Rectangle") but the area DirectX fills (in red and black) matches the Drag Rectangle, with the remainder to be painted with the window background color (green).
The DirectX Utility Toolkit (DXUT) didn't have this problem. Experimenting with their settings I found that setting DXGI_SWAP_CHAIN_DESC::SwapEffect = DXGI_SWAP_EFFECT_DISCARD would just paint the screen green (the window background color) during a sizemove. I assume that DXUT has their own special handling for when win32 enters a modal sizemove loop in order to display DirectX content during a sizemove.
DXGI_SWAP_EFFECT_DISCARD is part of the old blit mode presentation model. Notably it cant have DXGI_SWAP_CHAIN_DESC1::Scaling = DXGI_SCALING_NONE the scaling must be stretched to the window size. So my best guess is this behavior is due to the implementation of the flip presentation model (it flips a rectangle too small (black) and then covers by painting the rest green).
Does anyone know how to stop the win32 background from showing?
Edit:
Thanks to IInspectable! I can confirm the WS_EX_NOREDIRECTIONBITMAP extended style works: it stops the artifact from the win32 background showing
I reproduced the exact same behavior when using CreateSwapChainForComposition() with DirectComposition as I got using CreateSwapChainForHwnd().
This means that there are two path for pixels to get to the screen. The green pixels are going through the Redirection Surface. Hence, explicitly requesting WS_EX_NOREDIRECTIONBITMAP prevents any drawing through a Redirection Surface stopping the win32 background from showing.
The other path is the flip presentation behavior which is how the red and black pixels are get displayed. Hence, not using flip presentation when resizing also stops the win32 background from being shown.
There must be a bug with DWM: when there is a Redirection Surface, the clipping to prevent the swapchain's contents extending past the window is smaller than the redirection surface allowing it to be seen along the bottom/right edges.
There are two observations of interest:
when using WS_EX_LAYOUTRTL or manually positioning a IDCompositionVisual to the right edge of the screen with GetClientRect(), the swapchains contents are correctly position, but still clipped.
when using WS_EX_NOREDIRECTIONBITMAP the window`s nonclient area lines up with the contents of the swapchain rather than the swapchains contents being clipped
These observations would seam to imply that the cause of the issue is that DWM is using it's prefered size for the window size sometimes and the size of the redirection surface othertimes.
I'm trying to create a fullscreen and transparent OpenGL window in XLib, with the purpose of applying shaders to the screen. Imagine applying a blur or pixelate effect, for example. For now, i'm trying to do something really simple, such as rendering the current date in the middle, blurring the background and that's it.
What's the appropriate setup for this? Should i capture the desktop when my app launches and use that as a bitmap to manipulate in my shader? Or should i actually make some kind of transparency protocol?
I need to draw an overlay consisting of lines and text on top of another application. The application in question is a 3D outside world viewpoint, and the overlay is a head up display.
I don't have access to any type of callback from the outside world application to execute draw code in it's draw loop.
Drawing directly over the application's window will result in flickering as the draw loops will not be synchronized, so to me that doesn't seem like an option.
One method I can think of is to capture the outside world application's pixels and stream them into my application, so I can draw the overlay on top in the same draw loop, but that seems very inefficient.
Is there an efficient way to draw over the outside world application without flickering?
Is it possible to draw something over the final graphics card output / at the monitor's refresh rate?
P.s. It doesn't have to be OpenGL, but the HUD is already written in OpenGL so it would make it easier.
To repeat what I said in the comments, I've come across quite a few apps that hijack the 3D api calls and inject their own code to draw stuff right at the end of each frame - steam, teamspeak, mumble. Since it's in the same application there's no flickering and you can draw directly, rather than copying the result somewhere and compositing. I've never done it before and probably won't do a good job explaining it.
A relted question is here: Overlaying on a 3D fullscreen application
Say I'm writing a 2D cad program of some sort, and I want to be able to zoom in and scroll around my document. However, I also want full control over how my document is drawn and I want an OpenGL context for which to do the drawing. How do I do this? Should I subclass NSScrollView and do something I can't quite figure out there? Should I subclass NSOpenGLView and add a pair of NSScrollers and figure out how to draw them properly? Making NSScrollers and drawing them in a way that looks good natively looks nontrivial, but NSScrollViews seem to want to own all the content you might be scrolling, rather than letting me control the size of the knob of the scroll bar and other such things. I'd be completely content with giving a document size in pixels or some such, just the most important thing to me is that when I draw to (0,0) in my OpenGL context, I draw to the corner of the window, and not into some buffer that NSScrollView owns.
Should I subclass NSOpenGLView and add a pair of NSScrollers
Yes, since scrolling a OpenGL view doesn't make sense. You want to adjust the viewing volume (i.e. the parameters defining the projection matrix), rather than moving your viewport around. And that only works if you have manual control over the scroll bars.
I'm looking to replicate with Cocoa/Core Graphics the process which seems to occur on iOS when setting an image for a UITabBarItem. When the tab bar item is selected, the image is overlayed with a gradient.
For example,
becomes...
I'm unsure exactly what I should be doing to achieve this effect. It seems like the image is masking the gradient. Any pointers in the right direction (or code!) would be much appreciated.
You can use a monochrome CGImage with alpha channel (like most iPhone tool-/tabbar icons) as a mask. Basically, you'd use CGContextClipToMask with your monochrome image. Then you'd draw the gradient which is then clipped to the mask image. You might also want to have a look at the code of UMEKit, which implements this effect on Mac OS X (haven't looked at how exactly they do it, there are probably several ways).