Beware CGAffineTransformScale() negative zero

#import <ApplicationServices/ApplicationServices.h>

int main(int argc,char *argv){
   CGAffineTransform matrix;
   
   matrix=CGAffineTransformMakeTranslation(42,42);
   matrix=CGAffineTransformConcat(CGAffineTransformMakeScale(1,-1),matrix);
   
   printf("matrix=%g %g %g %g %g %g\n",matrix.a,matrix.b,matrix.c,matrix.d,matrix.tx,matrix.ty);

   matrix=CGAffineTransformMakeTranslation(42,42);
   matrix=CGAffineTransformScale(matrix,1,-1);
   
   printf("matrix=%g %g %g %g %g %g\n",matrix.a,matrix.b,matrix.c,matrix.d,matrix.tx,matrix.ty);

}

Generates:

matrix=1 0 0 -1 42 42
matrix=1 0 -0 -1 42 42

Yes, that is a negative zero.

While zero and negative zero are considered equal and produce the same results in most situations, there are cases where negative zero will give different results. e.g. 1.0 / 0.0 is positive infinity (greater than zero) and 1.0 / -0.0 is negative infinity (less than zero).

(OSX 10.5.4)

The CoreAnimation patent application

Framework for Graphics Animation and Compositing Operations

Final portrait of a dragonfly

This evening while hanging out at our neighbor's house this dragonfly decided to land on my leg and hang out. After it became clear he wasn't flying away with everyone looking at him I tried to motivate him with my finger, whereupon he crawled onto it. This became a novel moment and my wife grabbed the camera and I took some shots while he hung out. I decided perhaps he would like to go to the pond and placed him on a leaf, he promptly flew away, then crash landed into the pond and died.

Didn't order the special

An annoyance with properties

I can:

CGFloat x=someLayer.bounds.origin.x;

But I can't:

someLayer.bounds.origin.x=x;

Cocotron and programming salaries

The Unix Geek has a fun entry on programming salaries for languages, API's and operating systems


Good news for Cocotron developers with Objective-C and Win32 in the top tier! :)

CoreGraphics line rendering performance bug

In general CoreGraphics is brutally fast, but I've been noticing some situations where it isn't which I narrowed down to non-uniform scaling of the CTM.

This program demonstrates how non-uniform scaling the CTM can adversely affect line rendering performance. It draws a grid of lines with scaling in X and Y adjustable by sliders and a rotate slider to get feedback on how fast it can render.

There's no voodoo here, the bottleneck is CGContextDrawPath(), drawing the grid scaled 0.5/0.6, or 0.2/0.5 on my MBP can take half a second, whereas if it is scaled 0.5/0.5 rendering is a couple orders of magnitude faster.

CTMScaleBug.zip

10.5.3

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