- CoreGraphics/CGContextCanvas.j (635 lines) inlined into CGContext.j
at the former #include site inside the CPHTMLCanvasFeature branch
- the 11 one-line canvas delegation macros become plain functions;
their macro form was a 2008-era call-overhead optimization that
modern JITs make unnecessary
- the compatibility tables, hasPath path-semantics helper, backend
implementations and CGBitmapGraphicsContextCreate pass through
verbatim
- capp-build's compiled AppKit gains the canvas backend for the first
time: the deferred include previously omitted it entirely
- zero #define, #include or #pragma directives remain in AppKit or
Foundation sources
- CoreGraphics/CGContextVML.j removed; it implemented the CGContext
function family against Internet Explorer's VML, irrelevant in the
supported browser landscape for over a decade
- its self-replacing CGBitmapGraphicsContextCreate wrapper called
document.namespaces.add, an IE-only API — a latent crash on modern
browsers had the branch ever been selected
- CGContext.j: the CPVMLFeature branch of the load-time backend
selection removed; CPCompatibility.j: the CPVMLFeature constant and
its feature-table entry removed
- Tests/AppKit/CGContextTest.j: the vacuous VML-incompatibility
assertion removed
- the canvas backend and the no-canvas stubs are unchanged
Previously, Cappuccino was using preprocessor macros internally for the CGPoint/Size/Rect/Inset/Affine functions, as well as for CPRange. These macros had the same name as the corresponding function, but began with _. The functions were actually defined using the macros.
The motivation behind using macros was to increase performance by reducing function calls. However, there were a number of problems with this approach:
- There was an artificial dichotomy between _CG macros and the corresponding CG functions. We never completely replaced CG function calls with _CG macros. In fact, they were often mixed up in the same file. There was an extra burden on the programmer to remember to use the macro instead of the function.
- If a method call was passed as an argument to a macro, performance could actually be significantly *worse* than a function call. For example, _CGGetRectMakeCopy([view frame]) would expand to `{ origin:{ x:[view frame].origin.x, y:[view frame].origin.y }, size:{ width:[view frame].size.width, height:[view frame].size.height } }`. So instead of a single objj_msgSend and a single simple function call, we ended up with 4 objj_msgSend calls, which are way more expensive than simple function calls.
- Because of this expansion problem, to use macros efficiently required us to remember to use variables for all macro parameters. This didn't happen, and shouldn't have to happen.
- Finally, with modern Javascript engines, function call overhead is so small that it really isn't worth using the macros.
This commit eliminates the _CGGeometry, CGAffineTransformation and CPRange macros and replaces them with function calls.
BREAKING CHANGE:
The macros are no longer available. They could only be used with compiled code, but if there is any user code that used them, they will have to be replaced with the corresponding functions.
All classes (excluding the ones prefixed with underscores) in Foundation
and AppKit can now be loaded individually except CPOpenPanel and
CPSavePanel. These two classes have some sort of dependency cycle
that seems impossible to resolve without forward declarations (which
we don't have).
David Richardson
Martin Carlberg
daboe01
Alexandre Wilhelm
Antoine Mercadal
Alexander Ljungberg
Aparajita Fishman
Adam Radabaugh
Gerrit Riessen
Randall Luecke
Stephen Ierodiaconou
Francisco Ryan Tolmasky I
Klaas Pieter Annema
Paul Baumgart
lowell vizon
Ross Boucher