The bug I hoped I had fixed didn’t get fixed.

Sorry, guy who just submitted the scarlet bug report.

I can’t quite put into words the anger and frustration I feel right now. Plus, whenever I figure this out, it’s totally going to be the simplest, stupidest mistake on my part.

I think I fixed a huge, huge crasher that has affected Naked light for literally ever.

So far, I’ve received confirmation from one former crash victim that it no longer crashes. Hopefully his situation is not a fluke.

I think the crasher occurred for people with multiple displays (or possibly, only MacBook/Pros with external displays). (If I did in fact fix it, then yes, that was the issue).

I’m porting shapes to the CPU. Here it makes since to dip into Quartz, but first I needed a bridge so that Quartz can draw directly into Naked Anatomy’s buffers. After an hour or two of trying to figure out why it wouldn’t work via a simple CGCreateBitmapContext(…) call, I went the roundabout way: I created an NSBitmapImageRep with my buffer, created an NSGraphicsContext from that, and pulled out the graphicsPort to get my CGContextRef.

Took 5 minutes and a beer.

CGCreateBitmapContext-created contexts don’t seem to play nice with floats.

If for some reason Naked light couldn’t find an image to show for an item in your library (typically due to another bug or you deleting stuff willy-nilly in the library folder in the Finder), Naked light would just keep trying to find it. And trying. And trying.

And taking up about 100% of one of your CPUs even when idling.

A one line fix. The library has two code paths: preview versus high quality. With no image, it would continuously render previews because it never get the OK to switch to a high quality rendering. Now, if it can’t find an image, it doesn’t even bother drawing that nothing again in high quality.

I knew I had an email backlog. I didn’t realize how far back it went.

Sorry if you’re one of those people I took 3 whole weeks to respond to. That’s just awful.

I’m all caught up now, and will try to start always getting back within 24 hours again.

I had two experimental code paths with two different problems this morning.

1. I could reuse textures over and over again, which would crash intermittently if I was trying to use the texture on two threads (I couldn’t seem to get the locks in all the right places, which I assume is because Apple’s OpenGL implementation likely caches commands for later use).
2. I could create new textures every time I needed to upload some buffers into OpenGL. This created a monster memory leak.

I’ve fallen behind on responding to email—something that always bugs me when I do.

I should find some time to catch up tomorrow. 

Getting bug reports/feature requests/etc. is always extremely helpful—even if I don’t always respond right away—so please keep it coming! 

Some recent changes have made the canvas in Naked light much more responsive and in some cases “perfect” fast—i.e., 60 FPS.

Some more recent changes have mucked that up, and currently the blitting code is (temporarily) a mangled mess of old and new spaghetti code.

I hope I can straighten this all out tomorrow: I think I need to release everything on Friday regardless. If there’s something fundamentally wrong with the current approach I’ve taken, I’d rather know before spending days getting it perfect.

For some reason, loading documents in Naked light seems much quicker after 10.5.3. I have no idea why this is.

In some cases, I throw away a buffer for a texture sooner than OpenGL expects, causing a crash. I was never able to reproduce this bug, so it stayed there eating away in bug reports: the problem would only get aggravated if the texture was paged out of VRAM.

I assume this is the same bug that causes Naked light to crash immediately after returning to it when it’s been in the background for awhile.