save/restore the ctx around dashed line selections. #5392
Conversation
|
Line 400 in 57ef7bb What about putting the save/restore couple at start and end of that function i linked so that we cover also all the strokeStyle and fillStyle that happen in that function? Also please let's reproduce your use case of bug ( how were you drawing on the top canvas? ) and let's make a visual test from it. |
|
@AndrewJDR any chance to follow up? |
|
Yes apologies, just been busy. Please check out this jsfiddle: http://jsfiddle.net/qtb4prok/ Be sure to drag a selection box inside the canvas within 5 seconds, or the issue will not be reproduced (I don't know how to automate creating a selection box easily off the top of my head, so it's manual). Or you can drag anywhere during the box animation, and it will turn into a dashed box. |
|
As as i said the PR looks good if we can move the save/restore couple in the function i suggested. |
Previously, the line dash setting could be left enabled within _drawSelection() [which is called by renderTopLayer()], which could cause subsequent user-side line stroke calls on the top canvas to be dashed when they weren't explicitly specified to be by the user. See http://jsfiddle.net/qtb4prok/ for a repro.
AndrewJDR
force-pushed
the
save_restore_ctx_during_dashed_line_selections
branch
from
57ef7bb to
43e6965
Compare
|
Should be all set 👍 |
Previously, the line dash setting could be left enabled within _drawSelection() [which is called by renderTopLayer()], which could cause subsequent user-side line stroke calls on the top canvas to be dashed when they weren't explicitly specified to be by the user. See http://jsfiddle.net/qtb4prok/ for a repro.
Previously, the line dash setting could be left enabled, which could cause other user-side stroke calls on the top canvas to be dotted when they weren't intended to be.