emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the proper way to scale fringe-bitmaps for high-DPI displays


From: Clément Pit-Claudel
Subject: Re: What is the proper way to scale fringe-bitmaps for high-DPI displays?
Date: Wed, 20 Mar 2019 15:34:26 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 2019-03-20 13:32, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Wed, 20 Mar 2019 10:55:43 -0400
>>
>> Users on Flycheck are complaining about poor readability of our fringe 
>> bitmaps on high-DPI monitors, as the bitmaps look tiny on such screens.  An 
>> easy fix is to double the size of the bitmap, but it leaves users of low-DPI 
>> monitors in the cold.  A trickier fix would be to dynamically detect the 
>> current monitor's density, and pick the appropriate bitmap accordingly, but 
>> I'm not entirely sure how to do detect these high-DPI monitors:
>>
>> - x-display-monitor-attributes-list seems OK, but looks more complex than 
>> what we need (based on looking at the C code) — is it OK to call it 
>> repeatedly to figure out the current monitor's density for a given frame?
> 
> That'd be very inelegant, IMO.

Understood. Thanks for your input! (And for the quick answer)

> Instead, I think when a frame is created, we should record its
> high-DPI state in the frame structure, or maybe in the frame's
> parameters, and then use that when we prepare the fringe bitmaps for
> display.

That would be nice.  In fact, we already have code to detect high-DPI displays 
in C, in x_get_scale_factor in xterm.c (used to scale wavy underlines).  Would 
the way to go be to record the value returned by this function in the frame's 
parameters?
 
>> Also, how do applications typically deal with frames being moved from a 
>> low-DPI monitor to a high-DPI one? Is that an issue in practice?
> 
> If a frame can be moved from high-DPI to low-DPI, then I guess we will
> need to query the low-level interfaces which report that in
> update_frame or thereabouts.

Got it. Thanks!

I guess that another approach would be to support scalable images in the 
fringe, rather than bitmaps.  If the fringe image was SVG instead of a bitmap, 
for example, we could make it fill the whole width of the fringe.

Do you have a sense of how hard that would be?

Clément.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]