CoreGraphics Dashed Lines Bug #2(?)

These two images are the same path, stroked with dashes, drawn at different angles. Some of the corners render differently depending on the angle.

Compile the demonstration and drag the slider around for the full effect.

DashedLinesBug2.zip

10.5.2

CoreGraphics Dashed Lines, Bevel Joins Bug

This is two lines, one is solid black and the other is red and dashed, both 100pts wide, same end points. When the line join style is set to bevel and the ctm is rotated the dashes are overzealously clipped by CoreGraphics. The dashes should continue all the way up to the top as the black line does. It will also show up if the miter limit is zero which effectively uses bevel joins. It won't show up if you just draw the lines without the rotation. The bug will appear with various combinations of line widths, angles and dashes in a similar position along the edge of the view.

Example code here: http://www.objc.net/blog-media/2008-03-26/DashedLinesBug.zip

Shows up on 10.4.11 and 10.5.2

I noticed this while working on a new software renderer for Cocotron, the renderer was drawing the dashes and CG wasn't.

The Big Word Project entries

"cocoa" and "windows" for cocotron.org

The Big Word Project

Peaceful Atom and Cocotron

Every so often I get an email asking where I got the images for cocotron.org, to make a short story long ...

Cocotron.org was registered Sep 29, 2005, the day I came up with the name for the project. I had struggled for a long time with the name, trying to come up with something relevant, catchy, memorable and so on. The obvious thing would have been to create another *Step but it never sat well with me. OpenStep was a failure in the market, abandoned by Sun, superceded by Apple and never gained significant acceptance on the emerging Linux desktop. Making the association would have some name recognition but also come with a lot of baggage. So I waited for inspiration.

My father had collected and saved an inordinate amount of Stuff in his lifetime and I spent an inordinate amount of my lifetime sorting through the Stuff. Sitting there going through some papers with a trash bag I happened upon a small collection of items from the 1961 USSR Industrial Exposition in London. Among them was a booklet distributed by the former Soviet Union called "Peaceful Atom". I'm not sure if my father went or it was something from my grandfathers estate, but either way it spoke to me "Hey, don't throw me away!"



The booklet had all these wonderful propaganda pictures of atomic energy at work, in medicine, power plants and so on. My favorite, while a poorly lit shot, is the "Atomic Store" in Moscow. It was like gold in images, all these carefully done propaganda pictures to show off the Soviet Union's technology at an international forum. You'd spend a small fortune trying to stage images like this today. My father had a lot of old booklets, but most of them were from his lifetime and from the US or the UK which pose copyright issues. On its own as a government produced informational document the case for "Peaceful Atom" being public domain is pretty strong, being produced before the Soviet Union entered into international copyright agreements made it even stronger. So I decided this would be the imagery for the project. (While the originals may be public domain, my derivatives are not, if you want these or similar images, one word: eBay)

Flipping through the book words like "synchrocyclotron" and "synchrotron" jump out at you. Of course! "Cocoatron", but well, to simplify and help avoid the ire of Apple legal let's say "Cocotron".

The Cocotron on ohloh

I recently ran across ohloh, a networking-y site for open source projects, so I submitted Cocotron out of curiousity, here: The Cocotron on ohloh

The metrics are semi-interesting, amusing and useless at the same time.

Semi-interesting

The lines of codes/comments/blanks graphs.

Amusing

Project cost, $1.3 million, 25 years to develop.

"Very few source code comments". This is actually high considering most of the comments are license text.

Misrecognizing a small percentage of source as "Matlab" code.

Useless

The say they have something which scans all the source files for licenses to present a comprehensive view of multi-license projects, but despite almost all of the Cocotron source files having a generic MIT license in them, ohloh does not pick it up. (This is different than the project profile where I explicitly mark the project as MIT license)

cocotron.org facelift

I recently switched cocotron.org over to a new site I have been chipping away at. There were a few things I knew I needed to do, page generation using a better template system which would help with content organization and fix a big annoyance with the examples.

The original site was done using server side includes with a simple header&footer template. If you've used SSI's you know how extremely limited they are, especially in the older version of Apache my hosting provider is using. I'm sure some people have done amazing stuff with just SSI's, but that is not me. I decided to write a CGI program to generate pages using Foundation on OS X and then get it working on the Linux shared hosting account where cocotron.org lives. One bug fix later in Cocotron it was generating pages on the Linux account. Most of the work was reorganizing the html of the old content, coming up with the new layout and updating some content.

One recurring problem with the examples and building apps in general is that the DLL's and framework resources need to be copied into the same directory as the .EXE in order to run the program. The documentation does describe this, but automating it during the build process would make it all a lot easier. So there is a new program in CDT which fixes this problem called retargetBundle, it does a fast copy, using modification dates, to copy the DLL's and resources as the final build stage. If you have the latest CDT and build an example, it should be ready to run.

Satisfied for now with the page generator I'll be updating the content more regularly and probably work on some new dynamic aspects of the site. This will improve the site and increase the use and testing of Cocotron on Linux.

Globalization, Home Depot and Wood Trim

For the last year or so one of our ongoing projects around the house has been to finish a room above the garage. Most of the larger jobs have been contracted out, but we're doing the finish work ourselves. My wife and I painted (I got the ceiling), I installed flooring during Thanksgiving week and am now doing the trim.

I went down to Home Depot a few days ago, bought a bunch of trim which matches the rest of the house, polyurethaned it over the course of a couple days and set about installing it today. You could drive yourself crazy trying to make this kind of thing perfect and I am trying to get it done in a finite amount of time, so I give myself some allowance for fit. However, when I started putting up the window trim I started to wonder if I was missing something fundamental.

When I bought the trim I had noticed it came from Chile, which struck me as a long way away to obtain Pine, but, well, ok. Then as I was polyurethaning I noticed some of it was from New Zealand too. Pine from the other side of the planet! Well, ok. Then when I went to take these pictures I noticed some was from Mexico too. Ok, that almost seems reasonable.

But all these origins are actually the problem.





The Pine from New Zealand (right), despite have identical SKU's was milled differently than the Pine from Chile (left) and Mexico. The thinnest part of the trim is significantly thicker on the NZ Pine, and the profiles are ever so slightly different.



It doesn't look like much here, but when you put it up, this happens:





I had to run out today to get more trim, needless to say, I made sure it was all from the same country.

CGCreateShading example revisited for Leopard

I upgraded one of my machines to Leopard

The original post for Tiger: Radial Shader Fun

Better, I suppose.

Objective-C front-end for LLVM in the works

If you are at all interested in the future of the C/C++/Objective-C/Objective-C++ compiler(s) on OS X:

clang.llvm.org

Basically, Apple is working on a whole new compiler based on LLVM which does C/C++/Objective-C/Objective-C++ and is syntax compatible with gcc. The presentation is done by Steve Naroff a long-time NeXT/Apple engineer. Well worth the watch for commentary on where Apple is going, and why gcc doesn't cut it.

Apple has already contributed a lot of ARM work to LLVM, so I suspect this is the beginning of the end for gcc on OS X.

Interesting to note is that LLVM is BSD licensed.

More details:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-July/009817.html

VMware Fusion's shared folders suck

The Intel Mac and virtualization were a godsend for me, I could do cross-platform development all on one machine. No more sitting at a desk with a Mac and a PC, switching back and forth between keyboards and mice. I could get OS X, Windows 2000, XP, Vista and whatever Windows variation I wanted all packed up in a MacBook Pro.

My initial allegiance for virtualization was VMWare, they were established in the market and I had heard good things about their products. The Parallels beta changed that, it was available much sooner and it worked. I got my ideal system up and running in short order - Windows 2000 in a virtual machine running on OS X. Sweet! (Like a BMW with whitewall tires)

Shared folders were the first thing to be configured, I set them up and off I went on my merry way. I do my Windows build on OS X using a cross-compiler, and run it from the shared folder in Windows land. I bought Windows XP and Vista and was extremely pleased with the setup. They all shared the same folders and it worked like a champ.

At some point a few months back my machine locked up and I had to do a hard power down. Not thinking much of it at the time Parallels was running XP. A month or so later (I use Win2k regularly) I would discover that my XP virtual machine was trashed. Not knowing when it got trashed I'd have to dig through my backups for a good copy, annoying. But no rush, I could use 2k and Vista.

I recently began playing with OpenGL again in an attempt to get NSOpenGLView functional in Cocotron. The OpenGL performance on Win2k in Parallels is not very good so I was looking to use XP more often. I figured what better time than to give VMWare's Fusion a shot with a fresh install.

Setting things up were as painless as Parallels, I installed XP, set up the shared folders and started to use it for real work.

Then I started doing some head scratching.

I would make changes to my programs and they would not show up in Windows land. Fix a bug and it would still be there. Try to add some debugging output and it wouldn't show up. What the hell. The shared folder became a suspect. What I would come to discover is that changing a file on the Mac side would not necessarily show up on the Windows side. This was a complete hassle for me.

My workaround is to delete the file on the Windows side, then copy it in on the Mac side. It works, but what a goddamn headache. It should just work. Shared folders have always worked for me in Parallels , but shared folders in Fusion are broken in a final release product. Sigh!

All the fancy features are lost in this one basic thing.