Re: Points vs pixels in a bash script

[Ken Thomases via Cocoa-dev]

Except that Apple specifically says they're not.  From High Resolution 
Guidelines for OS X 
>:

> Note: The term points has its origin in the print industry, which defines 72 
> points as to equal 1 inch in physical space. When used in reference to high 
> resolution in OS X, points in user space do not have any relation to 
> measurements in the physical world.

In any case, it would be impossible for points to correspond to 1/72 of an 
inch, because a given physical screen size can correspond to a different number 
of points, depending on the display mode.

Regards,
Ken

> On Jun 8, 2020, at 6:01 PM, Jeff Younker via Cocoa-dev 
>  wrote:
> 
> Just as an aside, points are not Apple-specifc. They are a typesetting unit
> equivalent to 1/72 of an inch. It's the same unit used for font sizes.
> 
> -jeff
> 
> 
> On Mon, Jun 8, 2020 at 2:43 PM Gabriel Zachmann via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> 
>> I know this mailing list might not be the perfect fit for my question,
>> but maybe someone has an idea.
>> 
>> I have a problem converting points (I think) to pixels in a bash script.
>> I'd rather not write an extra C/Cocoa utility for that.
>> 
>> Using
>>   system_profiler SPDisplaysDataType
>> I can retrieve the size of a Mac's display in pixels.
>> 
>> However, the command
>> 
>>   tell application "System Events" to get the size of every window of
>> every process
>> 
>> (which I execute from my bash script using osascript) apparently does NOT
>> return window sizes in pixels. I guess it's the strange "Apple points"
>> units. According to my experiments, on my MacBook Pro Retina, for instance,
>> a fullscreen app (e.g., Keynote presentation) has a window size of 1680 x
>> 1050.
>> By contrast, system_profiler reports 2880 x 1800.
>> 
>> So, the question is: how can I determine the screen size of a Mac from my
>> bash script in the same units like "System Events" uses?
>> Or, how can I determine the factor by which I have to convert pixels into
>> those other units?
>> 
>> 
>> Many thanks in advance for any insights or hints.
>> 
>> Best regards, Gabriel
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/jeff%40drinktomi.com
>> 
>> This email sent to j...@drinktomi.com
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ken%40codeweavers.com
> 
> This email sent to k...@codeweavers.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Jeff Younker via Cocoa-dev]

Just as an aside, points are not Apple-specifc. They are a typesetting unit
equivalent to 1/72 of an inch. It's the same unit used for font sizes.

-jeff


On Mon, Jun 8, 2020 at 2:43 PM Gabriel Zachmann via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> I know this mailing list might not be the perfect fit for my question,
> but maybe someone has an idea.
>
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
>
> Using
>system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels.
>
> However, the command
>
>tell application "System Events" to get the size of every window of
> every process
>
> (which I execute from my bash script using osascript) apparently does NOT
> return window sizes in pixels. I guess it's the strange "Apple points"
> units. According to my experiments, on my MacBook Pro Retina, for instance,
> a fullscreen app (e.g., Keynote presentation) has a window size of 1680 x
> 1050.
> By contrast, system_profiler reports 2880 x 1800.
>
> So, the question is: how can I determine the screen size of a Mac from my
> bash script in the same units like "System Events" uses?
> Or, how can I determine the factor by which I have to convert pixels into
> those other units?
>
>
> Many thanks in advance for any insights or hints.
>
> Best regards, Gabriel
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jeff%40drinktomi.com
>
> This email sent to j...@drinktomi.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Carl Hoefs via Cocoa-dev]

Note that your AppleScript returns the size of ALL monitors combined. 
With four 1920x1080 monitors in a 2x2 arrangement it shows:

0, 0, 3840, 2160

-Carl



> On Jun 8, 2020, at 3:44 PM, Marco S Hyman via Cocoa-dev 
>  wrote:
> 
> Using
>>  system_profiler SPDisplaysDataType
>> I can retrieve the size of a Mac's display in pixels. 
>> 
>> However, the command
>> 
>>  tell application "System Events" to get the size of every window of every 
>> process
> 
> 
> tell application “Finder”
> set screen_resolution to bounds of window of desktop
> end tell
> 
> screen_resolution on my 5K iMac is 0, 0, 2560, 1440
> 
> Marc
> ___

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Steve Christensen via Cocoa-dev]

I don’t have an answer for your question, and I know that this doesn’t actually 
answer it below, but it may still provide some info to help you move forward.

The windowing system is always working in points from a coordinates point of 
view. So window.frame and view.frame are in points, not pixels. This allows 
drawing to be abstracted across screens that have different point scales 
(pixel-to-point size ratio). You specify everything in points and what that 
means when it’s time for the actual drawing to occur on a particular screen is 
handled for you.

I would suggest that you check out the NSScreen class, which provides 
properties such as the frame (in points) and backingScaleFactor (pixel-to-point 
ratio), as well as methods to convert between point- and pixel-based NSRects. 
Since it’s possible to, for example, have a 2x Retina display as the main 
screen and plug in an older 1x display, then move the window so it straddles 
the two screens, then there will not be a single scale value when calculating 
the number of pixels per point.

You can do things like iterate over all attached screens and find the largest 
backingScaleFactor, then use that to calculate the pixel size for an image, for 
example.


> On Jun 8, 2020, at 2:43 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I know this mailing list might not be the perfect fit for my question,
> but maybe someone has an idea.
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?
> 
> 
> Many thanks in advance for any insights or hints.
> 
> Best regards, Gabriel

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Marco S Hyman via Cocoa-dev]

Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process


tell application “Finder”
set screen_resolution to bounds of window of desktop
end tell

screen_resolution on my 5K iMac is 0, 0, 2560, 1440

Marc
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Ken Thomases via Cocoa-dev]

On Jun 8, 2020, at 4:43 PM, Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?

I'm not sure what you're trying to do necessarily makes sense.  In particular, 
you're not taking into account the current screen resolution (a.k.a. display 
mode).  The user can select different scaling for a Retina display in System 
Preferences > Displays.  So, a screen with that's physically 5120x2880 pixels 
is, by default, in a mode that's 2560x1440 points and 5120x2880 pixels in the 
backing buffer.  However, it may also be in a mode that's just 1600x900 points 
with a 3200x1800-pixel backing buffer.  Or a mode that's 3200x1800 points with 
a 6400x3600-pixel backing buffer (which is ultimately scaled down to the 
5120x2880 physical pixels of the display).

So, basically what I'm saying is that there's no fixed relationship between 
points (for window sizes, etc.) and the number of physical pixels of a 
display's size, even if you know the screen is a Retina display.

First, you're going to have to explain exactly what you're planning to do with 
the results of your calculation.  Do you really want the physical screen size?  
Or do you want the size of the current display mode?

Then, you probably are going to have to use APIs to get the info you need.  
However, you don't necessarily have to build a C utility for it.  You can 
invoke the Swift interpreter to execute code from your script.  Or, you could 
use Python and the PyObjC bridge.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Rob Petrovec via Cocoa-dev]

I don’t have an answer to your question, but to add some clarity Points are 
scale factor independent unit of measurement.  On a retina display there are 2 
pixels per point.  On a non-retina display there is 1 pixel per point.  Say 
Apple comes out with a display with a scale factor of 17.  That would mean that 
there are 17 pixels per point.  Hope that helps.

—Rob



> On Jun 8, 2020, at 3:43 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I know this mailing list might not be the perfect fit for my question,
> but maybe someone has an idea.
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?
> 
> 
> Many thanks in advance for any insights or hints.
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Points vs pixels in a bash script

[Gabriel Zachmann via Cocoa-dev]

I know this mailing list might not be the perfect fit for my question,
but maybe someone has an idea.

I have a problem converting points (I think) to pixels in a bash script.
I'd rather not write an extra C/Cocoa utility for that.

Using
   system_profiler SPDisplaysDataType
I can retrieve the size of a Mac's display in pixels. 

However, the command

   tell application "System Events" to get the size of every window of every 
process

(which I execute from my bash script using osascript) apparently does NOT 
return window sizes in pixels. I guess it's the strange "Apple points" units. 
According to my experiments, on my MacBook Pro Retina, for instance, a 
fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
By contrast, system_profiler reports 2880 x 1800.

So, the question is: how can I determine the screen size of a Mac from my bash 
script in the same units like "System Events" uses? 
Or, how can I determine the factor by which I have to convert pixels into those 
other units?


Many thanks in advance for any insights or hints.

Best regards, Gabriel



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Alex Zavatone via Cocoa-dev]

> On Jun 7, 2020, at 3:15 PM, Steve Christensen via Cocoa-dev 
>  wrote:
> 
> For slide shows that I’ve seen, they typically display each image for several 
> seconds at a time. If that’s the case, why can’t you just load the next image 
> from disk on a background queue while the current image is being displayed 
> and not have to worry about memory usage needed to cache multiple images? (I 
> am assuming that you’ll need to load each image once anyway.)

Yeah, that’s like the preloading I suggested on an earlier thread about loading 
screensaver images.  Then after an image has transitioned out of display, you 
can nil all references to it.  If you know the order of when images will be 
displayed and removed, you can even create a mechanism for loading what’s to 
come and removing what has disappeared.  Pre-calculate your display array, 
unload everything you don’t need anymore and preload everything that will be 
displayed next.  Just make sure you don’t unload anything that is used in the 
current or next display.

You’d have a previous list of images, a current list of images and a next list 
of images.

Just do some set operations to make sure you’re not unloading and loading the 
same image.  

For unloading, I’m referring to making the image reference count 0 and then 
nilling variables.  

So, you’d have this mechanism rolling along on a thread while you have another 
process for the display of the images.

How does that sound?  

> If caching is required—apologies if I missed the “why” in earlier 
> comments—then have you looked at NSCache? From the docs:
> 
> The NSCache class incorporates various auto-eviction policies, which ensure 
> that a cache doesn’t use too much of the system’s memory. If memory is needed 
> by other applications, these policies remove some items from the cache, 
> minimizing its memory footprint.
> 
> 
>> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Good question.
>> 
>> Well, some users want to feed my app with image files of 100 MB, even up to 
>> 400 MB (mostly jpeg compressed).
>> Those images have resolutions of over 8k, sometimes over 10k.
>> 
>> The slideshow app needs to be able to zoom into those images with at least a 
>> factor 2x scaling.
>> 
>> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
>> resolution maximum should be sufficient.
>> 
>> An 8k x 8k image needs at least 200 MB (1 byte per channel).
>> I don't know how CGImage stores the uncompressed images internally,
>> but my experience seems to indicate that it uses significantly more memory 
>> than that.
>> (maybe it uses two bytes per channel, or even floats, or there is some other 
>> aux data)
>> 
>>> What do you need a 1GB thumbnail for? There is no screen that can display 
>>> that. For a slideshow app you could scale your thumbnails at creation time 
>>> to the users biggest screen pixel size, don’t you think?
>>> 
>>> Christos Konidaris
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com