Mesh Gradients Bugs - Revision history

Tavmjong: /* Hard to Edit With Both Fill and Stroke Meshes */

2016-12-06T11:21:59Z

Hard to Edit With Both Fill and Stroke Meshes

← Older revision		Revision as of 11:21, 6 December 2016
Line 437:		Line 437:
	Adding lines would make the already busy screen very busy. Jabier had implemented node highlighting (select a node and the associated handles change to triangles that point to the corner node) as well as control curve highlighting (select a node and the associated control lines change color).		Adding lines would make the already busy screen very busy. Jabier had implemented node highlighting (select a node and the associated handles change to triangles that point to the corner node) as well as control curve highlighting (select a node and the associated control lines change color).

	=== Hard to Edit With Both Fill and Stroke Meshes ===		=== Hard to Edit With Both Fill and Stroke Meshes: Implemented ===

			<b>Implemented in trunk and 0.92.x.</b>

	<pre>		<pre>

Tavmjong: /* Hard to Associate Handles with Nodes */

2016-12-06T11:21:05Z

Hard to Associate Handles with Nodes

← Older revision		Revision as of 11:21, 6 December 2016
Line 427:		Line 427:
	</pre>		</pre>

	=== Hard to Associate Handles with Nodes ===		=== Hard to Associate Handles with Nodes: Implemented ===

			<b>Status: Implemented in trunk and 0.92.x.</b>

	<pre>		<pre>
	Sebastian: When bezier handles are near to each other it is hard to distinguish which one belongs to which corner node. Therefore bezier handles and their related corner nodes should be connected through a line like it's done within the vector tool.		Sebastian: When bezier handles are near to each other it is hard to distinguish which one belongs to which corner node. Therefore bezier handles and their related corner nodes should be connected through a line like it's done within the vector tool.
	</pre>		</pre>

			Adding lines would make the already busy screen very busy. Jabier had implemented node highlighting (select a node and the associated handles change to triangles that point to the corner node) as well as control curve highlighting (select a node and the associated control lines change color).

	=== Hard to Edit With Both Fill and Stroke Meshes ===		=== Hard to Edit With Both Fill and Stroke Meshes ===

Tavmjong: /* Hard to Distinguish Nodes and Handles */

2016-12-06T11:16:26Z

Hard to Distinguish Nodes and Handles

← Older revision		Revision as of 11:16, 6 December 2016
Line 419:		Line 419:
	Option 2 has been implemented in trunk.		Option 2 has been implemented in trunk.

	=== Hard to Distinguish Nodes and Handles ===		=== Hard to Distinguish Nodes and Handles: Implemented ===

			<b>Status: Implemented in trunk and 0.92.x.</b>

	<pre>		<pre>

Tavmjong: /* Memory Leak */

2016-12-06T10:37:58Z

Memory Leak

← Older revision		Revision as of 10:37, 6 December 2016
Line 257:		Line 257:
	</pre>		</pre>

	=== Memory Leak ===		=== Memory Leak: Partially Fixed ===

	<b>Status: Not blocker~~. Under study~~.</b>		<b>Status: Partially fixed in trunk and 0.92.x. Not blocker.</b>

	<pre>		<pre>
Line 269:		Line 269:
	<su_v> 4) set smoothing to 'Bicubic'		<su_v> 4) set smoothing to 'Bicubic'
	<su_v> 5) drag a couple of mesh nodes and monitor mem usage of inkscape process		<su_v> 5) drag a couple of mesh nodes and monitor mem usage of inkscape process
	<su_v> Tavmjong: another question wrt to interpolation: it appears that the behavior is not symmetrical (vertically)? more noticeable with bicubic smoothing, example (screen recording): https://dl.dropboxusercontent.com/u/65084033/irc/mesh-smoothing-1.gif
	~~<Tavmjong> su_v: I'll check on the memory usage. The asymmetry you are seeing maybe due to the order in which patches are painted (left to right, top to bottom).~~
	~~<su_v> Tavmjong: re interface, selecting nodes: did you consider adding support for <TAB> to select/cycle through mesh nodes?~~
	<su_v> minor issue when moving selected mesh nodes with keyboard (arrow keys): one of the nodes (last in selection, or first?) leaves handles in original position. display of handlees gets out-of-sync until mesh is deselected and reselected again.
	</pre>		</pre>

	==== Study ====		==== Study ====

			Clearing a mesh array did not delete all SPMeshNodes. This has been fixed.

	It appears that all gradients leak memory. ~~Mesh gradients may~~ leak ~~it faster~~ as ~~there are more Cairo calls. The bicubic mode creates 64 patches for every normal patch so it is not surprising that it leaks memory faster~~.		However, it appears that all gradients leak a small amount of memory. Moving a mesh handle does not appear to leak but moving a mesh corner does as does moving an end handle of a linear gradient.

	=== Incorrect status bar: Fixed ===		=== Incorrect status bar: Fixed ===

Tavmjong: /* Handles not updated */

2016-11-30T15:18:37Z

Handles not updated

← Older revision		Revision as of 15:18, 30 November 2016
Line 312:		Line 312:
	</pre>		</pre>

	=== Handles not updated ===		=== Handles not updated: Fixed ===

	<b>Status: ~~Not blocker~~</b>		<b>Status: Fixed in trunk and 0.92.x.</b>

	<pre>		<pre>
	<su_v> minor issue when moving selected mesh nodes with keyboard (arrow keys): one of the nodes (last in selection, or first?) leaves handles in original position. display of handlees gets out-of-sync until mesh is deselected and reselected again.		<su_v> minor issue when moving selected mesh nodes with keyboard (arrow keys): one of the nodes (last in selection, or first?) leaves handles in original position. display of handlees gets out-of-sync until mesh is deselected and reselected again.
	</pre>		</pre>


	=== Inserting row/column with double click: Fixed ===		=== Inserting row/column with double click: Fixed ===

Tavmjong at 08:59, 29 November 2016

2016-11-29T08:59:46Z

← Older revision		Revision as of 08:59, 29 November 2016
Line 321:		Line 321:


	=== Inserting row/column with double click: Fixed* ===		=== Inserting row/column with double click: Fixed ===

	<b>Status: Fixed in trunk. ~~Will backport to 0~~.~~92x~~.</b>		<b>Status: Fixed in trunk and 0.92.x.</b>

	<pre>		<pre>
Line 394:		Line 394:
	</pre>		</pre>

	=== Tweaking Color ===		=== Tweaking Color: Implemented (and rather cool!) ===

	<b>Status: Implemented in ~~Trunk~~</b>		<b>Status: Implemented in trunk and 0.92.x.</b>

	Allow corner node colors to be modified with Tweak Tool/		Allow corner node colors to be modified with Tweak Tool/
Line 406:		Line 406:
	Allow nodes to be moved with tweak tool.		Allow nodes to be moved with tweak tool.

	=== Keep Nodes Selected: Implemented ~~in trunk~~ ===		=== Keep Nodes Selected: Implemented ===

	<b>Status: Implemented in trunk~~, will backport to~~ 0.92.x.</b>		<b>Status: Implemented in trunk and 0.92.x.</b>

	<pre>		<pre>
Line 443:		Line 443:
	</pre>		</pre>

	=== Inconsistent Node Selection: Implemented* ===		=== Inconsistent Node Selection: Implemented ===

	Status: Implemented in trunk. ~~Will backport~~.		Status: Implemented in trunk and 0.92.x.

	<pre>		<pre>
Line 453:		Line 453:


	=== Selecting Nodes with Control Curves: Implemented* ===		=== Selecting Nodes with Control Curves: Implemented ===

	Status: Implemented in trunk. ~~Will backport~~.		Status: Implemented in trunk and 0.92.x.

	<pre>		<pre>

Tavmjong: /* Inconsistent Node Selection: Implemented* */

2016-11-23T12:01:38Z

Inconsistent Node Selection: Implemented*

← Older revision		Revision as of 12:01, 23 November 2016
Line 450:		Line 450:
	<vlada__> One more would be that editing mesh point isn't consistent with node editing logic. Sweep selection should remove all previously selected "nodes", and select newly chosen only.		<vlada__> One more would be that editing mesh point isn't consistent with node editing logic. Sweep selection should remove all previously selected "nodes", and select newly chosen only.
	<vlada__> Shift adds to selection. So that one is good		<vlada__> Shift adds to selection. So that one is good
			</pre>


			=== Selecting Nodes with Control Curves: Implemented* ===

			Status: Implemented in trunk. Will backport.

			<pre>
			It would be quite useful to be able to select nodes by clicking on the control lines. This would be especially useful for selecting a center node in a conical gradient (where multiple nodes are on top of each other).
	</pre>		</pre>

Tavmjong: /* Keep Nodes Selected: Partially implemented */

2016-11-21T11:37:25Z

Keep Nodes Selected: Partially implemented

← Older revision		Revision as of 11:37, 21 November 2016
Line 406:		Line 406:
	Allow nodes to be moved with tweak tool.		Allow nodes to be moved with tweak tool.

	=== Keep Nodes Selected: ~~Partially implemented~~ ===		=== Keep Nodes Selected: Implemented in trunk ===

	<b>Status: ~~Partially implemented~~ in trunk.</b>		<b>Status: Implemented in trunk, will backport to 0.92.x.</b>

	<pre>		<pre>
Line 421:		Line 421:
	# Save a list of which corner nodes are selected and reselect those nodes after all other changes are made.		# Save a list of which corner nodes are selected and reselect those nodes after all other changes are made.

	~~In the case of making the edges elliptical or in sampling color, the draggers do not need to be regenerated. Simply setting the variable "local_change" to true allows keeping the selection. This~~ has been implemented in trunk ~~and will be backported to 0.92.x~~.		Option 2 has been implemented in trunk.

	=== Hard to Distinguish Nodes and Handles ===		=== Hard to Distinguish Nodes and Handles ===

Tavmjong: /* Keep Nodes Selected */

2016-11-20T10:46:42Z

Keep Nodes Selected

← Older revision		Revision as of 10:46, 20 November 2016
Line 406:		Line 406:
	Allow nodes to be moved with tweak tool.		Allow nodes to be moved with tweak tool.

	=== Keep Nodes Selected ===		=== Keep Nodes Selected: Partially implemented ===

			<b>Status: Partially implemented in trunk.</b>

	<pre>		<pre>
Line 419:		Line 421:
	# Save a list of which corner nodes are selected and reselect those nodes after all other changes are made.		# Save a list of which corner nodes are selected and reselect those nodes after all other changes are made.

	In the case of making the edges elliptical or in sampling color, the ~~nodes~~ do not need to be regenerated. Simply setting the variable "local_change" to true allows keeping the selection. This has been implemented in trunk and will be backported to 0.92.x.		In the case of making the edges elliptical or in sampling color, the draggers do not need to be regenerated. Simply setting the variable "local_change" to true allows keeping the selection. This has been implemented in trunk and will be backported to 0.92.x.

	=== Hard to Distinguish Nodes and Handles ===		=== Hard to Distinguish Nodes and Handles ===

Tavmjong: /* Keep Nodes Selected */

2016-11-20T10:45:03Z

Keep Nodes Selected

← Older revision		Revision as of 10:45, 20 November 2016
Line 412:		Line 412:
	When multiple corner nodes are selected and you toggle the sides between beziers and lines or make them elliptical, the selection of the nodes is removed. I'd expect the selection to be kept.		When multiple corner nodes are selected and you toggle the sides between beziers and lines or make them elliptical, the selection of the nodes is removed. I'd expect the selection to be kept.
	</pre>		</pre>

			This is actually not trivial to implement as toggling between Beziers and lines adds/removes handles thus the handles (draggers) must be regenerated. Possible solutions:

			# Add code that prevents the regeneration of the corner draggers while allowing handle draggers to be regenerated.
			# Always generate handle draggers (even for lines) and turn their visibility on/off.
			# Save a list of which corner nodes are selected and reselect those nodes after all other changes are made.

			In the case of making the edges elliptical or in sampling color, the nodes do not need to be regenerated. Simply setting the variable "local_change" to true allows keeping the selection. This has been implemented in trunk and will be backported to 0.92.x.

	=== Hard to Distinguish Nodes and Handles ===		=== Hard to Distinguish Nodes and Handles ===