How do I draw normal flat text on top of an OpenGL scene using Quartz? I'm looking for the Mac equivalent of glXUseXFont() or wglUseFontBitmaps(): I just want to blast some text on the screen on top of the GL scene; I'm not interested in getting an image of the font into a texture, or scaling, rotating, occluding, spindling or mutilating it in any way.
Google has turned up a few things, but they all look insanely complicated (people giving the answer of "use the over-engineered library I wrote for that!" instead of just explaining it).
Update: Ok, it looks like aglUseFont() is what I want, but I don't get how to initialize AGL so that it can draw on my NSOpenGLView: if I ever call aglSetCurrentContext(), then regular GL activity stops showing up on the window at all (even if I never do any other AGL things). Are AGL and OpenGL fighting with each other? Do I have to synchronize aglChoosePixelFormat() with NSOpenGLPixelFormat somehow?
Update 2: I finally figured it out -- the answer is "you can't use NSOpenGLView when doing things that require an AGLContext, because NSOpenGLContext and AGLContext are orthogonal". But that's ok, because it turns out that NSOpenGLView doesn't really do much for you anyway: it just makes a context and keeps it current, and if you do that manually with the AGLContext, you can render GL onto any old NSWindow.
The IP block of the US Congress has been banned from Wikipedia!
(Incidentally, is there some trick to making Wikipedia work on the Treo? The pages are readable before they finish loading, but then they blow up: most of the text vanishes, except for some gigantic-font headlines.)
Update: There are several sites that provide PDA-oriented copies of Wikipedia, and pda.en.wapedia.org seems to be the best of a bad bunch. Most of them strip out all of the images; wapedia.org tries to include the images, but screws up on half of them.
I mentioned toxoplasmosa
the other day, and now there's a Straight Dope
about it! Plate. Shrimp. Plate-o-shrimp.
Here's where things get strange. While the link between toxoplasmosis and birth defects has long been recognized, scientists now suspect that T. gondii may cause schizophrenia too. That in itself represents a major change in thinking -- till recently the assumption, based on twin studies and the like, has been that schizophrenia is transmitted genetically. No way, scoffers say: schizophrenia is so profoundly disabling that sufferers tend not to reproduce. Germs are a likelier candidate. Studies typically have found T. gondii antibodies occurring in schizophrenics at twice the rate seen in control groups.
But get this. Forty-five percent of schizophrenics tested positive in one study for both T. gondii and LSD. To quote a recent paper: "These results support the hypothesis that T. gondii may cause schizophrenia and may do so by producing or triggering the production of an hallucinogenic chemical." [...] "Production of such a compound may have been favored by natural selection because an infected, hallucinating rodent would be more easily captured by a cat." In other words, schizophrenia in humans may be a side effect of T. gondii's attempt to set cats up with a steady supply of tripping mice, the better to ensure its own reproductive success.
So, the native MacOS port of xscreensaver is well under way. (And there was much rejoicing.)
Basically I'm doing it by re-implementing Xlib in terms of Quartz, so that the source code of the individual savers doesn't have to change. I also wrote code that reads the existing XML files and constructs Cocoa controls, so all the savers will have the same configuration UI as before, too. That was actually the hardest part so far.
I have some OSX hacking questions: <lj-cut text=" --More--(14%) ">
I've got an XCode project that will eventually include hundreds of .saver targets. Each of these is built from about a dozen source files, only one file of which differs in each target. XCode builds a dozen .o files for each target, instead of sharing the majority that they have in common (which is slow, and takes up a lot of space). What's the right way to share these? Build a .a? A bundle? And how do I do that in XCode? (I don't want to build a library that gets installed globally on the machine; I want each .saver bundle to be self-contained. I'd just like to optimize the build process.)
Answer: Add a ".a" target. Pretty straightforward.
Is there some sensible way to make XCode's "Build and Run" and "Build and Debug" commands work with .saver targets? If I double-click on the .saver product, it will launch System Preferences, as me if I want to re-install, and let me run it there, but that's a lot of clicking, so I've just been debugging them using a tiny test harness .app version. It's kinda kludgey though, because I have to modify what gets linked into that app when I want to switch from one saver to another.
Answer: no, not really. You can make "Build and Run" launch System Preferences, but then you still have to manually select the Screen Savers page.
How do you debug use of freed memory errors on OSX? MallocDebug and the various MallocCheckHeap* environment variables aren't being any help. Things like:
Target application (pid 18224) attempted to read address 0x55555575, which can't be read. and
MallocDebug can't do anything about this, so the app's just going to have to be terminated.
objc: FREED(id): message retain sent to freed object=0x3604a0
objc: FREED(id): message retain sent to freed object=0x38fd90
Sadly, most of the older screen savers are written in a very non-reentrant way: heavy use of global variables, and some use of static locals to hold state machines. This means that when the OSX screen saver framework creates more than one ScreenSaverView at once (e.g., the preview view and the full-screen view; or one view on each screen of a multi-head system) the two copies fight with each other and it all blows up.
So, the right way to fix this is to change the code so that they store all their state in a structure that gets passed around, like the more modern savers do. But that's a lot of really tedious, boring work and I'd rather avoid it.
Maybe I could have the ScreenSaverView fork() so that each instance actually runs the graphics code in a private address space? But I don't know whether Quartz is re-entrant in that way, and that sounds like a big hassle anyway. Any other ideas?
Answer: No good answer; I'll just fix them all to not use globals.
Likewise, the old savers aren't good about cleaning up after themselves: I'm sure most of them leak, because they assumed that when they stopped running, the process would exit and it didn't matter. I'm not really clear on how the OSX screen saver framework works, but it looks like it's just loading the .saver bundles right into its own address space and not sandboxing them in any way. What is the lifetime of the process that loads that bundle? If the answer is "until you log out", well,that could be a problem...
Is there some way to say that "all calls to malloc() between points A and B go into region X" and then at the end, just free region X in bulk? I know about NSAutoreleasePool, but I don't know if there's any mechanism like that that works with C code and plain-old-malloc.
Answer: malloc_create_zone(), malloc_zone_malloc() and malloc_destroy_zone() look promising here.
As far as I can tell, CGContextClipToRect() has no effect on anything anywhere anytime. WTF? Without this, the savers are able to write outside of their View and mess up the enclosing window (e.g., the enclosing System Preferences dialog.)
Answer: I was drawing while the wrong window was focused. Don't draw from within [ScreenSaverView startAnimation].
Part Barbarella, part Lexx!
"Schlafgras is based on a modular system, that allows for napping areas of different sizes. From using a single module within a regular office up to a "forest" made of grass everything is possible. While the outer parts of such a forest would only be suitable for sitting, its interior, protected by high, inflexible "stems", could offer the space for an intensive nap.
"The translucent sleeping-spheres have there origin in Ergotherapy, adapting to the shape of body, supporting and relieving the corresponding parts of the body and picking up the lighting-mood of "NAPMOSPHERE".
The stable forms of the spheres create a cavity, which guarantee the airflow and breathability of the capsule. It allows the individual to bury himself and relax fully."
Here's a music video for a crappy disco song:
Mstrkrft, Easy Love
. But don't bail on it before about a minute and a half in or you'll miss the joke.
I blame the Japanese for this. Ew.
This is one of the most ghoulish things I've heard about in a while:
She beat odds; dealer won't pay
When M. Smith was diagnosed with cancer and AIDS in the early 1990s, she was given two years to live. That she is still very much alive today is good news - to everyone but the people who bet big on her dying.
Had Smith perished on schedule, Life Partners Inc. would have made $60,000 on a $90,000 wager - a 66 percent return on the investment. Instead, the company that expected to make a profit on Smith's life insurance policy wound up spending $100,000 more keeping her alive.
Now, Life Partners' attempt to wriggle out of the relationship has led to one of the most morbid contract disputes ever filed in New Jersey Superior Court.
This is a pretty badly written article, in that I have a hard time telling who exactly is sueing whom, and on what basis, but I think what's going on is that the company is trying to simply pretend that they never had a contract with this woman in the first place. But the truly horrifying part is that this line of "investment" exists at all!
"They're not a charity. These people win by having her die fast. They were not counting on a revolution in the treatment of AIDS," notes Cohn, of the Cozen O'Connor firm, who took Smith's case for free.
Life Partners' president and General Counsel, Scott Peden, declined comment about the lawsuit - which he said he believes is the first of its kind in the company's 15-year history of helping "thousands of terminally ill patients."
We didn't buy her health insurance. There's no value there, it doesn't benefit us," Peden told me in a brief phone interview Friday.