Commit Graph
16 Commits
Author SHA1 Message Date
cacaodev 65dee154f7 Remove ignored argument _ 2016-02-06 20:39:49 +01:00
cacaodev 095a978120 Replace loops with arrayByApplyingBlock: 2016-01-17 20:54:43 +01:00
Aparajita Fishman afd5925499 Fixed: _CG and _CP macros were confusing and could degrade performance
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.
2013-03-13 12:22:10 -04:00
Alexander Ljungberg 1e6c7fa6d0 Fixes #1749. Fix CPGradient error introduced by 08ad614. 2013-02-12 16:41:54 +00:00
Alexander Ljungberg 08ad614611 CPGradient drawInBezierPath:angle:. 2013-02-06 16:36:33 +00:00
Alexander Ljungberg 4680f0fcc6 CPGradient initWithStartingColor:endingColor:. 2013-02-06 15:00:58 +00:00
Aparajita Fishman 866e1f00f7 Objj2 compiler fixes
- Each file compiles individually with no errors or warnings.
- Added missing imports.
- Fixed imports to remove circularity.
- Removed unnecessary imports.
- Added missing headers.
- Added missing action_button.png.
- Replace CPMakeRect with CGRectMake.
2013-01-23 15:48:56 +07:00
Aparajita Fishman 4f377bcebe Objj2 compiler fixes
Compiled all files individually:

- Added missing imports.
- Added @class/@global declarations to break circular dependencies.
- Misc. code cleanup.

Conflicts:
	AppKit/CPWindow/_CPWindow.j
	AppKit/Platform/DOM/CPPlatformWindow+DOM.j
2013-01-23 15:48:55 +07:00
Alexander Ljungberg 53334251b8 Fix a typo in CPGradient comment and attempt to better explain what's going on. 2012-03-12 12:04:34 +00:00
Alexander Ljungberg a069f2945b Optimise. 2012-03-11 22:13:05 +00:00
Alexander Ljungberg 5a0e1d7bb3 Support any angle in CPGradient drawInRect:angle:. 2012-03-11 19:40:22 +00:00
Alexander Ljungberg 74054442a2 CPGradient initWithColors:. 2012-03-11 19:38:02 +00:00
Alexander Ljungberg 59ef8329c0 Handle CPGradient colorSpace argument. 2012-03-11 15:37:45 +00:00
Alexander Ljungberg 20cffaa7fe Fix CPGradient angle. 2012-03-11 14:07:17 +00:00
Alexander Ljungberg c509e6131a Fixed: CPGradient reversed its colours. 2012-03-11 13:12:17 +00:00
Alexander Ljungberg 3d9ae42dbf Starter CPGradient with drawInRect:angle:. 2012-03-10 11:55:13 +00:00