Feature: add CAGradientLayer - #57
DTW-Thalion wants to merge 4 commits into
Conversation
The source and the header held the copyright banner and nothing else, so there was no class to message. Adds colors, locations, startPoint, endPoint and type, with the values Apple gives a fresh gradient layer: no colours, no locations, a start point of 0.5,0, an end point of 0.5,1 and a type of axial. Adds the three type names axial, radial and conic, and the entries their sections of AppleSupport.h and AppleSupportRevert.h were left empty for. This covers the properties. A gradient layer does not draw itself yet. Tests/quartzcore/CAGradientLayer/gradient.m: 17 assertions.
|
40+ open PRs is quite a bit. Most seem to be uncontroversial, albeit rather... lengthy. |
ivucica
left a comment
ivucica
left a comment
There was a problem hiding this comment.
I can accept this with clarification that it still doesn't do rendering, afaict
|
|
||
| [super dealloc]; | ||
| } | ||
|
|
There was a problem hiding this comment.
Should this not have some drawing code providing the content to be drawn? (100% behavior is not required, logically we can just hack our way around and store the content in bitmapcontext)
Or it should be clarified that this is as much a stub as the previous status, just a bit of compile time compatibility.
There was a problem hiding this comment.
TODO added, and you are right that it does not render.
It is more than compile time compatibility though. Before this the class did not exist at all, so [CAGradientLayer layer] had nothing to message. It now holds colors, locations, startPoint, endPoint and type, starts with the values Apple starts them with, and reads them back, so code that configures a gradient layer works and can be tested. What is missing is the drawing.
On updating the bitmap context from a KVO trigger: the method Apple uses for that is +needsDisplayForKey:, and CALayer does not have it here. It is not implemented anywhere in the framework, so calling it raises an unrecognized selector and respondsToSelector: answers NO. Three assertions came out of the test file for that reason. Apple answers NO from it for colors, locations and startPoint, so whatever redraws a gradient layer there is not driven through that method.
Rendering is coming, but in a later batch of PRs - for my own sanity :). On the current list there are another 40 to 50 changes to come, and the drawing for this class sits behind the layer display path. I am building this onion up layer by layer and trying to ensure MacOS compatibility at each step. Very keen to get the rendering done as well as we just did a lot of backend parity work with opal in the past week.
Let's just add the TODO then into the code in case this does not get implemented. Although given how much everything is generated, the relevant content can be returned, updated in bitmap context upon a KVO trigger |
2 participants
Source/CAGradientLayer.mandHeaders/QuartzCore/CAGradientLayer.hheld the copyright banner and nothing else. There was no class, so[CAGradientLayer layer]had nothing to message.Adds the class with
colors,locations,startPoint,endPointandtype, and the three gradient type names.The values a fresh gradient layer holds are Apple's: no colours, no locations, a start point of 0.5,0 and an end point of 0.5,1, and a type of
axial. The type names areaxial,radialandconic. A type that is not one of the three is kept as it was given, which is also what Apple does.AppleSupport.handAppleSupportRevert.hget the class and the three constants, which theirCAGradientLayer.hsections were left empty for.This covers the properties. A gradient layer does not draw itself yet, which needs the layer display path rather than anything in this diff.
Tests/quartzcore/CAGradientLayer/gradient.mis 17 assertions. Whole suite 44.Apple answers NO from
+needsDisplayForKey:forcolors,locationsandstartPoint. CALayer has no+needsDisplayForKey:here at all, so that is not checked and is left for whoever adds it.