I'm developing a screenshot application working in fullscreen mode. I have a bug report about issues with MBP Retina, but I have no idea how to test and fix them. It looks like QuartzDebug can change displays to HiDPI mode, but I'm not sure that will do the trick. Can't find any "Retina Emultaion" related topics in Apple docs.
So my question is how can I test app (not just icons, but whole fullscreen application) for being compatible with retina display without buying one.
It's actually all in the Apple docs, though slightly hard to find: Testing High Resolution Content.
I'll sum it up for you: you should always test on a real device (or go to the Apple Store and put your application on to one of their demo retinas). But as an intermediate step, emulating the retina works too.
Quartz Debug's HiDPI mode works for this, and is a method Apple delineates as one to test with. You can also tint high resolution images using the command (in Terminal)
defaults write -g CGContextHighlight2xScaledImages YES
Related
Apple iMac & MacBook lineup uses high-resolution display branded as "Retina Display" which by default, macOS will set the screen resolution below the native screen resolution. For example on the 13-inch Retina MacBook Pro, which comes with native resolution of 2560-by-1600, macOS will set the default resolution to 1280-by-800 with option to scaled to other screen resolution (1024-by-640, 1440-by-900, and 1680-by-1050) on Settings app.
However, on Windows (including the latest version) screen resolution are by default, set to the native screen resolution with "Scaling" function to increases the elements sizing. For example on a 15-inch laptop, which comes with a Full HD display, Windows will set the default resolution to the 1920-by-1080 with scaling set to 100% but recommended to 125%. Setting a higher scaling in turns result in certain elements displayed blurry.
Hence, why is this case?
An operating system can work without screens. You could for example start your computer (either running Windows, or MacOSX, or Linux), and run some application app (or app.exe on Windows) on that command line.
Now, imagine you type app (without the ENTER key) in some command window, unplug your screen, and type the ENTER key. You app has still started (and perhaps detected that no screen is available, only if that app is a GUI application opening a window by using some widget toolkit). If your app is not a GUI application but a command line one (eg cp which copy files) it can successfully execute.
In practice, your screen is today used by some display server. And your application don't show directly pixels on the screen: it interacts with your display server which generally is the only process accessing the screen (more precisely, your graphics card).
So you need to learn how to tune or configure your display server. And that of course is operating system and display server specific. On MacOSX and and Windows and on Linux they are very different (and Linux even has several ones, e.g. Xorg or Wayland). On MacOSX it is Quartz.
I'm working on a Mac app, and one of the NSTableViews seems to have a little lag when I scroll it, but I'm not sure if I'm just imagining it.
The Instruments manual has a section on how to measure the frame rate of an iOS app, but when I try it for my Cocoa app, Instruments.app says "This instrument does not support the macOS platform".
Is there any (relatively easy) way to measure the FPS of my table view when scrolling?
I think what you are looking for is Quartz Debug.
Go to https://developer.apple.com/download/more/, download Additional Tools for Xcode.
After you open Quartz Debug, Command + 3 will reveal a frame meter.
Here's the gist: we have an Air app that displays bitmaps at full screen, original size and scaled. On the Mac, these bitmaps look great (antialiased and smooth). On Windows (regardless of machine), they look pixelated and terrible.
We've updated Air and it still looks bad under the latest Air build. Is there something that we can do programmatically to fix this, or is there a platform issue that we don't know about?
Did you try to set the Smooth parameter as true?
var YOUR_BITMAP_OBJECT = Bitmap(YOUR_BITMAPDATA_OBJECT);
YOUR_BITMAP_OBJECT.smoothing = true;
Also be sure the export has the correct compression (recomendable more than 80%).
Check the resolution diference in Windows versus Mac, maybe in Windows it's higher.
What is your current render mode? i suggest to set render mode to CPU.
I have a PDF that seems to have some internal color profile attached. If I render this in iPhone simulator the colors come out as they look in Photoshop which apparently can parse this color profile. If I render the same PDF on Mac I get the same colors (less bright, muddy) as in Preview and Pixelmator.
Is there some way how I can achieve the same (correct) rendering result on Mac as I was getting in iPhone simulator?
On iOS Simulator, I used CGColorSpaceCreateDeviceRGB with a kCGImageAlphaPremultipliedFirst bitmap context. I also set rendering intent kCGRenderingIntentPerceptual, though I don't know if this makes any difference.
on Mac I tried the same settings, as well as all the different kinds of color spaces, but I'm never able to achieve the same result us in Simulator.
I also tried the two ICC based approaches mentioned here: http://developer.apple.com/library/mac/#qa/qa1396/_index.html
I'm getting desperate. What is different between iOS simulator which gets the colors right and Mac? I thought iOS doesn't do color correction, but Mac does? Right now I am drawing the individual pages with PDFKit. Is there a difference in PDFKit on Mac versus iOS related to color correction that makes it work properly on iOS Simulator, but fails on Mac?
I also took a JPG that was rendered from this PDF in iOS Simulator, put it into a new PDF in Preview and there preview and my Mac rendering yielded exactly the same colors as the input.
It looks to me like iOS Simulator has a magical ability to use a color profile embedded in this PDF which Preview or Quartz on Mac does not.
Please help!
kind regards
Oliver Drobnik
I don't know exactly how simulator works, but I can assure you that both Preview and iOS have very incorrect handling of certain features of PDF files; especially when it comes to color management, transparency, overprint, advanced compression of images etc...
Two tips:
On Mac, open the PDF file in Adobe Reader (free download from Adobe.com). The color you see in Reader should be very close to the actual truth. If your PDF file contains ICC profiles (for objects in the file or in the output intent, meaning for the whole file) it will be used correctly. On iOS, also look at Adobe Reader - it currently is the best (highest quality) display tool on that platform.
Secondly, if you want to know what the simulator or some other tool can or cannot do, have a look at the test patches from the GWG (http://gwg.org/ghentoutputsuite.phtml). These patches were designed to give very easy to interpret results on whether certain tools or printers can handle specific PDF features.
These two steps should at least tell you what works and where it works. That should make it easier to figure out what you need to correct.
Unfortunately this is a confirmed bug in CGPDF on Mac. It manifests itself if you have CMYK as a transparency color space. iOS ignores this correctly, the Mac messes up the colors.
I'm looking to target a website specifically for an iPad but we don't have any Macs in house for testing. What's the most accurate way to test the site on a PC? I image I could use the Safari browser and shrink the window down to approximate the iPad screen size but I wonder if there's a better method out there.
If you target a website specifically for a particular device, buy that particular device. This doesn't only apply to iPad.
Two caveats I noticed a lot of websites have for a touch-oriented device like an iPad, iPhone:
The mouse-hover event isn't generated. So, the HTML/CSS/Javascript menu structure which works without clicking on a WebKit browser (like Safari) on a mouse-oriented device might stop working completely.
The scrolling event (coming from a flick of a finger) is not passed to elements inside a page; instead it just scrolls the entire page. A subelement shown with a scroll bar on a non-touch-oriented device might be shown without the scroll bar at all. So, sometimes you lose the ability to scroll inside a subelement.
There might be other caveats. It's really difficult to imagine all the way a device might behave differently from a mouse-oriented device; so, buy an iPad.
By the way, it's of no use to buy a Mac in this situation: Safari on a Mac still behaves (as far as the mouse/touch events are concerned) rather differently from Safari on an iPad/iPhone. An iPad can be paired with a Windows PC.
See this Apple document for a few advices for preparing a web page for the iPad.
I'd just use Safari, as the mobile version uses the same rendering engine (though possibly modified to fit the iPads resources).
It should display the same, if not close.
You can try to use online imitation services.
For example http://app.crossbrowsertesting.com/, or https://saucelabs.com/. They provide lots of imitations environments, for different devices and OS. You can test the site, that is already in the web, or your local files.
I myself am working currently with app.crossbrowsertesting.com for the first time. It really shows the problem, that the client encountered on his iPad. Also have good notices about these services from experienced developer, a friend of mine.