Change Details

Avoid computationally expensive copying operations when only some settings have been modified. This is done by adding support for updating parameters without tagging for copy-on-write. Currently only mesh data blocks are supported, other data-blocks can be added individually. This prepares for changing values such as edit-mesh auto-smooth angle in edit-mode without duplicating all mesh-data. The benefit will only be seen when the user interface no longer tags all ID's for copy on write updates. ---- ### Notes - This patch is a follow up to {D11337}, from the discussion that followed on from this, Sergey suggested to change the behavior of parameters. - When allocated arrays in the source mesh have been freed an explicit copy-on-write tag is now needed (this patch replaces `ID_RECALC_GEOMETRY` with `ID_RECALC_COPY_ON_WRITE` where necessary). Otherwise a mesh in edit-mode could have it's COW-id data-block pointing to freed memory (when memory is shared between the original and the copied data). In practice this only happens in a few places //(such as flushing edit-data to the ID data-block for rendering).// Although it's possible for Python to cause this situation when performing mesh editing operations while still being in edit-mode - so it's important the correct recalculation tag is used. ### Open Topics - Exactly what counts is the perimeter should to be clearly defined. Currently data which is directly attached to the ID data-block is used. For mesh-data this happens to be straightforward. For other ID types the division isn't so clear, for example, would we consider a changed modifier value to be the parameter of an object? //(I'd this makes sense, however it complicates the update function)//. - Some details from this patch that should be changed, if the general design is acceptable. - `ID_TYPE_SUPPORTS_PARAMS_WITHOUT_COW` moved to a function. - `BKE_mesh_copy_settings_ex` could be replaced with a dedicated function, or we could have a callback in `IDTypeInfo`. ### Further Work While looking into this patch I found other cases where copy-on-write is performed which can be avoided. - Even though this patch removes copy-on-write updates when changing parameters, `rna_property_update` is currently tagging `ID_RECALC_COPY_ON_WRITE` for all ID types that use copy-on-write. This could be removed as neither F-curve or the Python API do this, however I'd rather this be done as part of a separate patch as it has wider implications for non-animated values that rely on this for updates. - We may want to have more control to limit when a full copy-on-write is performed. As far as I can see there is no way to express that a parameter changed that should re-evaluate geometry without running a redundant copy-on-write. For example changing the auto-smooth angle only needs to copy the parameter & recalculate modifies, there is no need to copy over all geometry data from the original mesh.

Avoid computationally expensive copying operations when only some settings have been modified. This is done by adding support for updating parameters without tagging for copy-on-write. Currently only mesh data blocks are supported, other data-blocks can be added individually. This prepares for changing values such as edit-mesh auto-smooth angle in edit-mode without duplicating all mesh-data. The benefit will only be seen when the user interface no longer tags all ID's for copy on write updates. ---- ### Notes - This patch is a follow up to {D11337}, from the discussion that followed on from this, Sergey suggested to change the behavior of parameters. - When allocated arrays in the source mesh have been freed an explicit copy-on-write tag is now needed (this patch replaces `ID_RECALC_GEOMETRY` with `ID_RECALC_COPY_ON_WRITE` where necessary). Otherwise a mesh in edit-mode could have it's COW-id data-block pointing to freed memory (when memory is shared between the original and the copied data). In practice this only happens in a few places //(such as flushing edit-data to the ID data-block for rendering).// Although it's possible for Python to cause this situation when performing mesh editing operations while still being in edit-mode - so it's important the correct recalculation tag is used. ### Open Topics - Exactly what counts as a parameter should to be clearly defined. Currently data which is directly attached to the ID data-block is used. For mesh-data this happens to be straightforward. For other ID types the division isn't so clear, for example, would we consider a changed modifier value to be the parameter of an object? //(I'd this makes sense, however it complicates the update function)//. - Some details from this patch that should be changed, if the general design is acceptable. - `ID_TYPE_SUPPORTS_PARAMS_WITHOUT_COW` moved to a function. - `BKE_mesh_copy_settings_ex` could be replaced with a dedicated function, or we could have a callback in `IDTypeInfo`. ### Further Work While looking into this patch I found other cases where copy-on-write is performed which can be avoided. - Even though this patch removes copy-on-write updates when changing parameters, `rna_property_update` is currently tagging `ID_RECALC_COPY_ON_WRITE` for all ID types that use copy-on-write. This could be removed as neither F-curve or the Python API do this, however I'd rather this be done as part of a separate patch as it has wider implications for non-animated values that rely on this for updates. - We may want to have more control to limit when a full copy-on-write is performed. As far as I can see there is no way to express that a parameter changed that should re-evaluate geometry without running a redundant copy-on-write. For example changing the auto-smooth angle only needs to copy the parameter & recalculate modifies, there is no need to copy over all geometry data from the original mesh.

Avoid computationally expensive copying operations when only some settings have been modified. This is done by adding support for updating parameters without tagging for copy-on-write. Currently only mesh data blocks are supported, other data-blocks can be added individually. This prepares for changing values such as edit-mesh auto-smooth angle in edit-mode without duplicating all mesh-data. The benefit will only be seen when the user interface no longer tags all ID's for copy on write updates. ---- ### Notes - This patch is a follow up to {D11337}, from the discussion that followed on from this, Sergey suggested to change the behavior of parameters. - When allocated arrays in the source mesh have been freed an explicit copy-on-write tag is now needed (this patch replaces `ID_RECALC_GEOMETRY` with `ID_RECALC_COPY_ON_WRITE` where necessary). Otherwise a mesh in edit-mode could have it's COW-id data-block pointing to freed memory (when memory is shared between the original and the copied data). In practice this only happens in a few places //(such as flushing edit-data to the ID data-block for rendering).// Although it's possible for Python to cause this situation when performing mesh editing operations while still being in edit-mode - so it's important the correct recalculation tag is used. ### Open Topics - Exactly what counts is the perias a parameter should to be clearly defined. Currently data which is directly attached to the ID data-block is used. For mesh-data this happens to be straightforward. For other ID types the division isn't so clear, for example, would we consider a changed modifier value to be the parameter of an object? //(I'd this makes sense, however it complicates the update function)//. - Some details from this patch that should be changed, if the general design is acceptable. - `ID_TYPE_SUPPORTS_PARAMS_WITHOUT_COW` moved to a function. - `BKE_mesh_copy_settings_ex` could be replaced with a dedicated function, or we could have a callback in `IDTypeInfo`. ### Further Work While looking into this patch I found other cases where copy-on-write is performed which can be avoided. - Even though this patch removes copy-on-write updates when changing parameters, `rna_property_update` is currently tagging `ID_RECALC_COPY_ON_WRITE` for all ID types that use copy-on-write. This could be removed as neither F-curve or the Python API do this, however I'd rather this be done as part of a separate patch as it has wider implications for non-animated values that rely on this for updates. - We may want to have more control to limit when a full copy-on-write is performed. As far as I can see there is no way to express that a parameter changed that should re-evaluate geometry without running a redundant copy-on-write. For example changing the auto-smooth angle only needs to copy the parameter & recalculate modifies, there is no need to copy over all geometry data from the original mesh.