You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There were several issues related to Node bounds calculation and I think it makes sense to keep all discussions in one place. This is actually a complicated task, because bounds calculation requires rendering context and in fact it's only accessible after drawing. However users don't want to think about such implementation details, instead they want to be able to access Node bounds immediately after creation and access actual information even after some updates.
This task might be implemented during several milestones, so we need to provide useful workaround for current issues. So here is a plan:
We'll provide temporary public utility method to calculate Node bounds. This method will create synthetic rendering context and calculate bounds using this context once. This step is workaround to solve current issues.
We'll provide Node.bounds() -> Rect method. This method will work immediately and access actual information. In the first version we'll just use utility method from step 1.
Implementation from step 2 will be very slow and we actually don't need to recalculate bounds on each call, because we can just use cache to remember bounds. Moreover, during rendering we calculate bounds anyway, so if we render Node we don't need to use synthetic context. So on this step we'll provide complicated implementation to make a fast and useful solution to calculate bounds.
Finally, good implementation will allow us to add ability to monitor Node.bounds changes and it will make possible complicated layouts for nodes.
The text was updated successfully, but these errors were encountered:
Thanks for your answer in #240 and thanks for thinking about my suggestions. But I don't really understand the second part of your answer: In Swift you can have read only properties (https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID261). So calling Node.bounds is much more correct (for me), because the "bounds" is just a property of the Node and not a function. If you follow the development of the Cocoa-API, you also can notice, that with Swift a lot of things were changed from methods to properties (if I remember right, isHidden() was a method and is now a read-only property). For me a function is usually doing some stuff (for example "hide" or "activate" and properties are returning values (like "isHidden" or "isActivated"). With computed properties and read-only properties this is much better to divide.
There were several issues related to
Node
bounds calculation and I think it makes sense to keep all discussions in one place. This is actually a complicated task, because bounds calculation requires rendering context and in fact it's only accessible after drawing. However users don't want to think about such implementation details, instead they want to be able to accessNode
bounds immediately after creation and access actual information even after some updates.This task might be implemented during several milestones, so we need to provide useful workaround for current issues. So here is a plan:
Node
bounds. This method will create synthetic rendering context and calculate bounds using this context once. This step is workaround to solve current issues.Node.bounds() -> Rect
method. This method will work immediately and access actual information. In the first version we'll just use utility method from step 1.Node
we don't need to use synthetic context. So on this step we'll provide complicated implementation to make a fast and useful solution to calculate bounds.Node.bounds
changes and it will make possible complicated layouts for nodes.The text was updated successfully, but these errors were encountered: