Capturing an image of an off-screen window with CGWindowListCreateImage is a common way to create QuickLook style zoom-in animations, but this seems create an image with the wrong background colour, slightly lighter than the real window.
This causes a flash at the end of the animation which kind of ruins the effect.
Does anyone have any idea why this happens and what can be done about it?
EDIT: I created a demonstration app for this problem. It is a bit large and complex for a Stack Overflow question, but the relevant code is probably in the ZoomingWindow.m methods takeSnapshot and makeAndPrepareSnapshotWindow.
Setting the window appearance to textured in Interface Builder fixed this. Of course that also changes the color of the window, but that is acceptable in this particular case.
Related
I have a need. I need to make a window. The glass on the window is transparent. I have found some examples:
https://threejs.org/examples/#webgl_materials_shaders_fresnel
https://threejs.org/examples/#webgl_materials_cubemap_refraction
The background of these examples is static pictures.
My background is dynamic. How can I do it?
Maybe you can use THREE.Refractor like shown in this example. It allows you to create a refractive see-through surface. You might have to adjust the respective shader program in order to achieve your intended visual result (the default shader of THREE.Refractor does not perform any distortions).
We need to overlay a target window with a custom shape and tracks the position of the target window such that the overlay drawing always appears above it. Also, the overlay drawing should appear in screenshots taken using BitBlt or PrintClient by screen-capturing tools like Camtasia, Debut, etc. Also, moving the target window around should not leave traces of the drawing at earlier location. The target window is not made using our code.
So far we've tried several ways but each method has its problems:
1) Layered Window:
Using a layered window as the child/owned window of the target window is the easiest thing and it works. But the problem is on Windows 7 and XP, layered windows do not appear in a BitBlt done without the CAPTUREBLT flag and the screen-capturing tools may call BitBlt without the flag, thereby skipping our window from the capture.
2) Region Window:
The crude approach to support all Windows versions then is to use a region window using SetWindowRgn and make the target window its owner. However, region windows are generally very slow in rendering complex shapes and also impact the performance of other windows, sometimes to the point of freezing the application. Region window also leaves traces on dragging the application window.
3) Subclassing and Drawing on HDC:
Another approach is to sub-class the target window and draw the shape on its HDC on the OnPaint() event inside the window procedure hook. The shape can be drawn on the desktop window instead too. The problem is that applications may draw without a paint event, like when some text is selected using the cursor, and such drawing may erase a part of the custom drawing. Tracking all possible paint events is not a good way to do this.
4) Drawing continuously in a timer:
The last resort is to draw the custom shape on the target window in a timer continuously so the drawing is always above the target, even on text selection. But this may show a bit of flicker when the text is selected. Not to mention, it is very performance heavy to draw constantly.
Question
What is the best way to achieve an overlay drawing which works on all Windows versions (since XP) at the same time appearing in screen-captures. We've exhausted all approaches. Is there some method I'm missing? Can the above mentioned ways be used with some improvement? Is DirectX an option? I'm looking for methods with fast rendering capacity to achieve this. Appreciate any help!
I think the best solution to draw an overlay window, is to use a double-buffered technique GDI, just like in this example:
Overlay Drawing in CScrollView
I have myself the same task, and the only solution was that one. Hope it help you.
I am using Xcode 6.4 and find the canvas/background colour of the interface builder to be terrible. ViewControllers have a general whitish colour, so does the canvas. It makes viewing rather uncomfortable as there is no contrast between the canvas and the objects I work with (view controllers etc). Is there any way I could change the canvas colour please?
As far as my research into this went, there is no way to change the canvas colour.
UPDATE
There seems to indeed be a way to do this (thanks to deej): here is a link
The context menu from dock items is not only translucent but also blurs the contents behind it, Is this effect availible for translucent floating panels? This is the same effect used in Sheet Alert dialogs (e.g. quit with unsaved changes) but in that case the transparency is different, and the background is light rather than dark
Some background, we have a pro app that is frequently used full screen, and our floating palettes have some transparency, but obviously the more transparency we have the harder it is to read the text on them when the background is very active/noisy, if we could have a slight blur we would be able to greatly improve the readability on the text while still allowing some context of "whats behind the palette"
I think this is what you want: Using Core Image Filters On/Under a NSWindow
Beware that this is private API though, so if you're developing for the Mac App Store, this would be a problem.
I would like to create an effect than an image zooms up from a thumbnail size to full screen.
I am not sure what's the right steps to achieve this. Should I create a transparent full screen window and animate a layer on top of it?
Take a look at this CoreGraphics example. Specifically, take a look at the "grow" and "shrink" animations. That's how Apple does it, and that's what you'll want to do too.
Your solution of a transparent window with a CALayer inside is probably the best supported way to do it.
One thing that seems like it should be a good solution (at least it's the first thing I thought of when I wanted to do this) but isn't is NSView's enterFullScreenMode:withOptions:. If memory serves, it was originally meant to do what you're talking about here, but the animation was taken out and it generally doesn't work that well now.