-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix scaling of timeline images #1941
Fix scaling of timeline images #1941
Conversation
📱 Scan the QR code below to install the build (arm64 only) for this PR. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #1941 +/- ##
========================================
Coverage 67.60% 67.60%
========================================
Files 1349 1349
Lines 33786 33784 -2
Branches 7261 7261
========================================
Hits 22840 22840
+ Misses 7496 7495 -1
+ Partials 3450 3449 -1 ☔ View full report in Codecov by Sentry. |
Could we test those in the iOS app, to compare what they look like? Maybe I messed up the implementation, or maybe that's just what their algorithm does. |
Honestly I think we should keep cropping, thats what other messenger apps are doing. We could just have a bigger maxHeight maybe. @VolkerJunginger |
This is what something similar looks like on iOS: This is what it looks like on Android with these changes: And this is what it looks like in the app at the moment (it looks empty, but it's actually cropping the center of both images): And this is what Whatsapp does with them (thanks @ganfra): In Telegram it seems like they just refuse to display them as actual images 😅 : So it seems like there isn't a 'fits all' solution for this... Maybe we should keep this new strategy for images with normal aspect ratios and use the cropping one for images with extreme aspect ratios, such as these? Maybe we could add some kind of indicator to mark them as cropped, so the user knows it can be expanded, or use the telegram alternative, but that makes things way more complex. |
Just my two cents as a user: I think the WhatsApp and pre-PR solutions are worse, because they are misleading about the contents of the image. It's not clear that I wasn't just sent a black square, whereas at least with the element-x iOS and telegram solutions I can be like okay, there's more detail than I can easily see from the timeline image, let me download it or click and zoom. The new element-x android solution is okay, but the background color being much larger than the image and the image not being centered in it feels unnecessary and is a bit visually awkward and distracting. In that sense maybe it could be made to conform more to the element-x iOS version. The final note I'd like to make that the rounded corners of the messages would have a larger negative impact on these very narrow images if the background is not present, as shown in the iOS version. Maybe it would be good to make the background just wide or tall enough to capture the rounded corner, so the image can remain rectilinear while providing the least distracting background? Not sure the exact ideal solution to that, but the rounded corner cutting into the image and obscuring some of it is worth avoiding or at least considering in the design. |
The blurhash as background looks good and I like how the rounded corners aren't impacting the image. I also like how there is no timestamp overlapping with the image in the Telegram desktop version. I think this aspect is worth considering for Element, too. I see no reason why a design couldn't be made that avoids overlapping with the image while being as good as the current one in all other respects. Not trying to criticize, just sharing my opinion that keeping the image completely unmodified and unobscured seems strictly better. |
I was on holidays last week, I'm continuing with this work now. @VolkerJunginger , @amshakal what do you think about the issue found above and the possible solutions? To me, the blurhash one looks like the best option, and as a second option the telegram Android one where images with a width or height smaller than a min value don't actually show a preview (last spoiler tag here. In any case, doing any of these changes would mean doing the equivalent on iOS. I think the blurhash one should be fairly easy to do since all we'd had to do is not replace the loading blurhash background with the loaded image, but overlay them. |
Always display a white background for them.
af29f9f
to
2b76aeb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update. There is an issue regarding the background color, else I think it's fine.
It's a shame that we do not have a preview with the image and the blurhash behind. Not a P1 to investigate this thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to have a background color, else the bubble does not render nicely...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what iOS looks like and what we've decided to use for now, given the deadline, since otherwise it would mean extra work for the iOS team, although this will probably be revisited soon. I took into account the suggestions to have a white background so images with transparency render nicely.
Maybe we could add a subtle border radius for these images so the bubble keeps its shape, something like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have the bubble background color and white background for the image only (and maybe black background on dark theme)?
Like this this is not OK I think, but yes, definitely better with the bubble border.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the bubble color I've got this:
Light | Dark |
---|---|
And I think it's fine.
We may want to improve the rendering of images with transparency in another PR, since applying a white background should be done to all images generated by users: room avatars, user avatars, images in timeline, etc. But note that Element Web done not add background to the images. They just let see the current background if they have an alpha layer.
@amshakal do you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this makes sense to me. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... and this will also fix this issue.
} else { | ||
ElementTheme.colors.messageFromOtherBackground | ||
val backgroundBubbleColor = when { | ||
!state.displayBackground -> Color.White |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should use background color of the bubble, see my remark on the screenshots.
…t images will be rendered with the default bubble background color.
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
Type of change
Content
The scaling behaviour now matches iOS:
Motivation and context
Fixes #1940.
Screenshots / GIFs
In the PR.
Tests
Tested devices
Checklist