From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Carlos Pita <carlosjosepita@gmail.com>, 37932@debbugs.gnu.org
Subject: bug#37932: [PATCH] Support hidpi fringes and images with Cairo
Date: Sun, 27 Oct 2019 09:22:06 +0100 [thread overview]
Message-ID: <m2a79mr429.fsf@gmail.com> (raw)
In-Reply-To: <83r22zvpg4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Oct 2019 12:14:19 +0300")
>>>>> On Sat, 26 Oct 2019 12:14:19 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> * It removes the auto :scale property. I think this is the right thing
>> to do, applications that want to use the :scale parameter to transform
>> their images shouldn't lose the hidpi scaling nor explicitly call
>> image-compute-scaling-factor.
If I read the patch correctly, you now auto-scale inside image.c,
which shouldn't change anything when not using :scale. What's the
effect when code passes in eg :scale 2? Autoscaling + frame scaling,
so for a frame where scale == 2 we get * 4? I guess that would be
sensible, but weʼd need to explain it clearly. [1]
Eli> I don't think I'm qualified to make an intelligent decision on this by
Eli> myself (and you just asked the question not long ago, and proceeded to
Eli> coding without giving anyone any time to answer it :-(). I don't know
Eli> enough about this to make such a decision. maybe Robert, Alan, and
Eli> others would chime in and voice their opinions. failing that, please
Eli> tell more about the pro's and con's here, so that we could see what
Eli> kind of trade-offs are we talking about.
I think Lars did the autoscaling work. If things continue to work as
before for the normal case, and we explain the interaction between
:scale and frame scale I have no objections.
Robert
Footnotes:
[1] And it would get people out of the "1 physical display pixel == 1
logical display pixel" mindset that needed to be fixed in so many
places in the X backend.
next prev parent reply other threads:[~2019-10-27 8:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-26 2:17 bug#37932: [PATCH] Support hidpi fringes and images with Cairo Carlos Pita
2019-10-26 2:30 ` Carlos Pita
2019-10-26 6:01 ` Carlos Pita
2019-10-26 6:43 ` Carlos Pita
2019-10-26 8:05 ` Carlos Pita
2019-10-26 9:14 ` Eli Zaretskii
2019-10-26 9:18 ` Carlos Pita
2019-10-27 8:22 ` Robert Pluim [this message]
2019-10-27 17:08 ` Carlos Pita
2019-10-27 17:10 ` Carlos Pita
2024-01-10 22:15 ` Stefan Kangas
2024-01-11 17:35 ` Carlos Pita
2024-01-11 18:21 ` Stefan Kangas
2024-01-11 18:38 ` Carlos Pita
2024-01-11 19:31 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2a79mr429.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=37932@debbugs.gnu.org \
--cc=carlosjosepita@gmail.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).