Thanks for the sample files. I've asked engineering to take a look. Workaround: put the layer into transform and drag around until the pixels appear, then you can nudge it into exact position.
Thanks for the sample files. I've asked engineering to take a look. Workaround: put the layer into transform and drag around until the pixels appear, then you can nudge it into exact position.
@peter.f , is this a general problem with all older smart objects, or just this specific one? I could imagine that this particular case might be falling victim to our canvas layout where the line falls between pixels, and we round down (to null) for that thin line. If the workaround Jeff suggests works, then I'm inclined to let this issue ride, as inserting additional draw routines in for this narrow use case might be an expensive toll to pay for all smart objects.
Let me know if this makes sense; thanks for the report!
It’s a general problem. I never noticed this problem with older versions (can’t remember when it showed up, sorry). Now it occurs with both new and old smart objects.
As you say, it’s most noticeable with objects that have a thin line. Unfortunately, most of my work (UI design) has thin lines. And I use included smart objects a lot.
I can understand that a line can be on ‘between pixels’. However, in the test files I sent, all elements are positioned on integer pixel coordinates (in the smart object) and the smart object itself is also positioned on integer pixels coordinate. To be sure it’s not the UI that rounds the values, I’ve enterend the coordinates manually (not sure I did that in the files I sent you; I just tried it now). Same problem.
Note that I would love to have a 'Snap to Pixel’ option like in Illustrator. I now have to check the coordinates whenever I place something (to avoid blurry edges). If that option would also help this current issue, I have no problem with letting it ride. Otherwise, well, it’s a business decision you have to make…
Ah, @peter.f , I think I'm getting closer. This only happens for me when using the Transform command, and only with transparent backgrounds (move tool and non transparent background seems good); are you seeing it affecting non transparent backgrounds in any of your other use cases?
Checking ‘deactivate native canvas’ does not improve the situation. I’m working on a 5K 27” iMac (2019), with a Radeon Pro 580X 8GB graphics card. Monitor resolution is 5120 x 2880. Preferences > Interface > ‘UI scaling’ is set to ‘Auto’ and disabled. I’ve switch ‘deactivate’ back off.
The background makes no difference (in the container file): transparent or white, it’s all the same: the lines disappear (both with ‘deactivate native canvas’ on or off). (BTW: previously only the horizontal line would disappear; now both lines are not showing up. Odd.)
The only way to get these lines back is by using the Transform command. The Move tool doesn’t.
I still have this issue in the latest & greatest, PS 24.3 (updated 5 minutes ago). That's the reason I came here; I hadn't seen the issue in a long time, and I did remember that you mentioned a workaround. Luckily enough, that still works 🙂
I assume that engineering didn't find anything suspicious in my samples files (otherwise I wouldn't be here...). Am I really the only one that has this issue?
6
Replies
AdChoices
