How can I capture the screen with Haskell on Mac OS X?
I've read Screen capture in Haskell?. But I'm working on a Mac Mini. So, the Windows solution is not applicable and the GTK solution does not work because it only captures a black screen. GTK in Macs only captures black screens.
How can I capture the screen with … and OpenGL?
Only with some luck. OpenGL is primarily a drawing API and the contents of the main framebuffer are undefined unless it's drawn to by OpenGL functions themself. That OpenGL could be abused was due to the way graphics system did manage their on-screen windows' framebuffers: After a window without predefined background color/brush was created, its initial framebuffer content was simply everything that was on the screen right before the window's creation. If a OpenGL context is created on top of this, the framebuffer could be read out using glReadPixels, that way creating a screenshot.
Today window compositing has become the norm which makes abusing OpenGL for taking screenshots almost impossible. With compositing each window has its own off-screen framebuffer and the screen's contents are composited only at the end. If you used that method outlined above, which relies on uninitialized memory containing the desired content, on a compositing window system, the results will vary wildly, between solid clear color, over wildly distorted junk fragments, to data noise.
Since taking a screenshot reliably must take into account a lot of idiosyncrasy of the system this is to happen on, it's virtually impossible to write a truly portable screenshot program.
And OpenGL is definitely the wrong tool for it, no matter that people (including myself) were able to abuse it for such in the past.
I programmed this C code to capture the screen of Macs and to show it in an OpenGL window through the function glDrawPixels:
opengl-capture.c
http://pastebin.com/pMH2rDNH
Coding the FFI for Haskell is quite trivial. I'll do it soon.
This might be useful to find the solution in C:
NeHe Productions - Using gluUnProject
http://nehe.gamedev.net/article/using_gluunproject/16013/
Apple Mailing Lists - Re: Screen snapshot example code posted
http://lists.apple.com/archives/cocoa-dev/2005/Aug/msg00901.html
Compiling OpenGL programs on Windows, Linux and OS X
http://goanna.cs.rmit.edu.au/~gl/teaching/Interactive3D/2012/compiling.html
Grab Mac OS Screen using GL_RGB format
Related
We've encountered a strange problem on newer laptops using built-in graphic cards.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK).
Afterwards we parse the feedback buffer. This has worked for many years.
Now we have a problem with glyphs containing holes (only on platforms with built-in graphic cards):
wglUseFontOutlines works perfectly. If we just draw the returned display lists, everything is fine. However, the token stream generated with GL_FEEDBACK is corrupt. The debugger shows nothing unusual, all functions return with success and the parsing itself works fine too. It is really the binary data generated by GL_FEEDBACK mode, which is wrong.
Has anyone else encountered this problem?
And is there an alternative way to obtain outlines and fillings for true type fonts on Windows?
I'm just guessing into the blue here: The GL_SELECT and GL_FEEDBACK rendering modes were usually not supported by widespread GPU driver OpenGL implementations. Only a handful graphics cards from the previous century actually did support these rendering modes. Hence you would almost always fall back into a software implementation when using those modes.
However given modern GPU's vastly more flexible feedback mechanisms, the latest drivers could actually try to implement those rendering modes using GPU features (somewhat weird, because those modi have been removed from modern OpenGL profiles). Anyway, this could be the reason why you're experiencing these problems.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK). Afterwards we parse the feedback buffer.
That's a cool Rube-Goldberg machine. Why don't you simply cut the middleman and obtain the glyph outlines directly using the appropriate Windows GDI functions (GetGlyphOutline) for this? This is what wglUseFontOutlines is using internally anyway.
L.S.,
A year ago I made a very simple screen saver using Quartz Composer on Snow Leopard (SL).
The screen saver captures the input of the built-in camera with the "video capture"-patch and uses the images as input for the environment parameter of the "GLSL shader"-patch as found in the GLSL Environment Map.qtz stock example. The shader in turn maps the video capture on the famous 3D teapot, creating the illusion of a chrome teapot mirroring the person in front of the iMac or MB. You can find the screen saver here: Compresses QC source
Under Mountain Lion (ML) the output of the video capture fails to function as input for the envirnment of the GLSL shader patch.
The video capture still works though. Because you can still can use it as the input for the image parameter for the teapot-patch.
Furthermore, it doesn't matter whether I run the screen saver as a screen saver or in the QC runner.
Anybody any idea what's happening? The question boils down to: Why is it under ML not possible to use the video capture output as environment for the GLSL shader patch?
The screen saver, as simpel as it is, is quite popular and it would be a shame if people can't enjoy it any more.
I'm eagerly looking forward to a solution!
I would like to access the whole contents of a Mac OSX screen, not to take a screenshot, but modify the final (or final as possible) rendering of the screen.
Can anyone point me in the direction of any Cocoa / Quartz or other, API documentation on this? In a would like to access manipulate part of the OSX render pipeline, not for just one app but the whole screen.
Thanks
Ross
Edit: I have found CGGetDisplaysWithOpenGLDisplayMask. Wondering if I can use OpenGL shaders on the main screen.
You can't install a shader on the screen, as you can't get to the screen's underlying GL representation. You can, however, access the pixel data.
Take a look at CGDisplayCreateImageForRect(). In the same documentation set you'll find information about registering callback functions to find out when certain areas of the screen are being updated.
I'm currently writing an OpenGL renderer and am part-way through writing some classes for enumerating display adaptors, devices and modes for use in drop-down lists.
I'm using EnumDisplayDevices to get the adaptors and then EnumDisplaySettings for each device, giving me bpp, width, height and refresh rate. However I'm not sure how to find out which modes are available full-screen (there doesn't appear to be a flag for it in the DEVMODE structure). Can I assume all modes listed can in-principle be instantiated full-screen?
As a follow up question, is this approach to device enumeration generally the best way of getting the required information on Windows?
OpenGL has not this distinction between windowed and fullscreen mode. If you want an OpenGL program to be fullscreen you just set the window to be toplevel, borderless, without decoration, stay on top and maximum size.
The above is actually a dumb question. By definition windowed mode must be the current display settings. All other modes must be available full-screen (provided the OS supports them, i.e. 640x480 not advisable in Vista/7).
Hmmph, not correct at all, and with an attitude too. You have variety of functions that can be used.
SetPixelFormat, ChoosePixelFormat, ChangeDisplaySettings.
The PixelFormat functions will let you enumerator available modes. ChangeDisplaySettings with allow you to set whatever screen mode (including bit depth) your app wants. Look them up in MSDN.
I recently had a client contact me asking for an update to his project that I used to maintain/develop years ago.
It was done using Macromedia Director (now Adobe Director) and Lingo. Since I haven't developed anything using these technology in such a long time I need some assistance.
The majority of the changes are simple, but what has got me stumped is making the application be able to toggle between full-screen projector and windowed-mode.
This is how it is organised:
I have a stub projector, which is lightweight and ensures a quick start-time.
The stub projector loads the main movie. ("#::Content:Main")
This stub projector is published with in full-screen mode.
Now, I can create a projector that is windowed and one that is full-screen mode by publishing separate executables. However what the client wants is the ability to switch this at runtime - is this even possible?
I have found a few workarounds that kinda work (setting the display-rect and stage-rect to the desktop size) but introduce numerous compatibility issues.
Any advice? Solutions?
I am tempted to say that it isn't possible to switch at runtime and recommend that he publishes either a full-screen or a windowed version.
For future reference: http://www.directorforum.com/showthread.php?p=38795#post38795
Well there are different ways to
define "full screen", but all can be
done at runtime:
1) The projector automatically adjusts
the computer's display resolution to
match the dimensions of the movie and
hides the taskbar/dock. This is
generally what "full screen" means in
modern parlance. You can check out
various Xtras for switching the
resolution on the fly.
2) In Director terms, publishing a
projector 'full screen' just means
that the projector window has no
titlebar, takes up the full dimensions
of the display, hides the
taskbar/dock, and has the movie
content centered on screen framed by a
solid background color. This is a
pretty lame implementation of full
screen since it doesn't make the movie
appear any bigger onscreen. This can
be set at runtime by manipulating the
rects that you mention and using an
Xtra to hide the taskbar. Not sure
what "compatibility issues" you ran
into.
3) Graphically stretch the movie so
that its actual content takes up the
entire screen. The easiest way to do
this is by altering the drawRect. But
this can result in distorted graphics
depending on how much stretching is
occurring, since no antialiasing is
used to smooth the stretched pixels.