As part of automation, I want to compare images by taking screenshot and the baseline image. Will be executing the same on different OS(linux, win). On executing in different OS, the screen resolution changes and image comparison fails. Currently I am doing it with Selenium+java. Can anybody suggest me any way or a different tool to achieve it?
So make baselines for each environment you're testing on and have the test compare with the correct one for that platform (or just with all of them and flag as passed if any of them matches).
I'm not so sure this entire "compare screenshots" is a good way to test things (you just hit one snag, another one can be that different browsers (and even versions of the same browser) render things slightly differently.
The key thing here is the resolution, you must ensure that resolution is the same for base images and those you capture during test.
Set size of the browser window to fixed size, eg. (1920x1080),
Make all screenshots in this resolution,
During the test: before each image-comparison check if the window size is (1920x1080) if not I change it temporarily,
Take screenshot,
Compare image with original one
Do window maximize
Other solution is to capture screenshots of single WebElement rather
than whole page, because WebElements often are resolution independent.
Related
I am making a settings menu for my game. I have created every graphics setting I want, except changing the screen resolution. This is what I tried first. I didn't know what I should provide for the target, though.
What I tried first
For some reason, this didn't work. I'm guessing I should have provided a different target. Can somebody help me with this?
Since this is one of the highest results on google I figured I'd reply here.
Using console commands to set resolution absolutely DOES NOT WORK for shipping builds where console commands are disabled. It's better to use Get Game User Settings + Set Screen Resolution + Apply Resolution Settings nodes.
Is this a PC game? If so, this is the node I've used for altering resolution in the past, utilizing the r.setRes command:
If you have variable [width] x [height] parameters, have a function build the string and pass the return value to that node. Note: after the WxH, the f stands for fullscreen.
Credit for image: https://answers.unrealengine.com/questions/26895/how-can-i-change-games-resolution-in-blueprints.html
I'm using the newest version of Xcode and Swift.
I was googling around to make my KWWebView even faster and found the following:
webConfiguration.suppressesIncrementalRendering = true
Documentation says the following:
A Boolean value indicating whether the web view suppresses content
rendering until it is fully loaded into memory.
But what does this mean? Does it mean, the html doesn't not get rendered and shown as long as not all resources like images and javascript files are completely loaded by the WKWebView?
As stated in the documentation it's a flag to tell the webview engine to wait or not till things are set and ready. whether to scan the document (html+related resources) to check for what to be redrawn periodically, or just await the full stuff to be loaded and ready.
WebEngine:
Rendering is a progressive process that depends on the assets (js, Css, images..) that will compose the page. It is important to understand that Turning this feature on or off will simply turn the algorithm of rendering on/off for loaded content.
How to make my page faster?
A lot of factors, rendering algorithm (engine's), how heavy your scripts are(bundle, memory allocation,event pass through and handling, etc..), the size of the images, how well structured your CSS is, and its hierarchical selector orgnisation(css parsing and application).
The order of which the assets are loaded( included) in the page.
You can always check the profiling of your page in (devtools for example) on a modern browser to see how things go, what size of memory it allocates, the bundle size, time for scripting, how the page is designed to consume/utilise device resources.
To make the long story short:
Generally speaking there are THREE main phases with a total of five steps through which your page has to go while living in the browser:
PHASE A: MEMORY/CALCULATION (CPU)
1- Scripting:
PHASE B:( PROCESSING CPU mainly)
2- Styling
3- Layout
PHASE C: (GPU POWER!)
4- Paint
5- Composition
When the browser decides to to update it has to go through these, either a full pass or a partial pass will make a lot of difference. consider the following example
if you have a div, and you decided to create an animation that moves it from the left edge of the screen to the right edge, you see developers doing two approaches:
THOSE WHO JUST WRITE CODE:
change the left value of the div style over time. ( simple right?)
THOSE WHO KNOW THE STUFF:
do a transfom by using translateX or translate3D.
both ways will work, the first will eat up your CPU, while the second will run at a very high FPS.
WHY ?
The first approach plays with sacred left value, that means the browser will have to re-calculate the new left (STEP1) > check style (STEP2) > THEN do a new LAYOUT (STEP 3) > Do a Paint ( step 4) > THEN enter Composition phase (STEP 5)
this will cost a full pass 5 stages that is totally unnecessary!!
The other approach on the other hand, will not require anything but a composition (one step #5) because the matrix manipulation in the GPU (pretty strong ability!) can handle displacements implied by using the translate3d or translateX!! you will see people talking about including a translate3d prop on your CSS elements to push performance (huh!) but the real reason is the above explained. so knowing what happens under the hood can save you.
supperess rendering is about waiting to load everything before starting to show things up, or simply try to handle things as they load..
A presentable image starts out in VK_IMAGE_LAYOUT_UNDEFINED but will be VK_IMAGE_LAYOUT_PRESENT_SRC_KHR after they have been presented once.
A lot of examples do a transition of all vkImages to VK_IMAGE_LAYOUT_PRESENT_SRC_KHR immediately after creating the vkSwapchain. Which allows them to use an VK_IMAGE_LAYOUT_PRESENT_SRC_KHR for oldLayout. But doing the transition right after creation of the swapchain is not allowed.
Use of a presentable image must occur only after the image is returned by vkAcquireNextImageKHR, and before it is presented by vkQueuePresentKHR. This includes transitioning the image layout and rendering commands.
What are my options to deal with the swapchain image layouts correctly?
There are 3 options. Ordered from best to worst (IMO):
Simply set the initialLayout of the attachment in the renderPass to VK_IMAGE_LAYOUT_UNDEFINED or transition from VK_IMAGE_LAYOUT_UNDEFINED every time. This is allowed and will imply that you don't care about the data still in the image. Most often you will be clearing or fully overwriting the image anyway.
valid Usage [of VkImageMemoryBarrier]
[...]
oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED, VK_IMAGE_LAYOUT_PREINITIALIZED or the current layout of the image region affected by the barrier
Keep track of which images have been through the pipeline already and select the oldLayout accordingly when recording the commandBuffer.
Do the transitions after creating the swapchain but using vkAcquireNextImageKHR and vkQueuePresentKHR to ensure the application owns the image while transitioning. There is no guarantee in which order you get the images So it may be possible one image never gets returned.
I've been trying a fourth option but some input on its validity would be useful. When creating the swapchain the images are in VK_IMAGE_LAYOUT_UNDEFINED, which to me seems to indicate that they're all available to the application because they need VK_IMAGE_LAYOUT_PRESENT_SRC_KHR for presentation and so shouldn't be displayed or in queue. I didn't find anything in the spec that would guarantee this however.
The spec says that we can acquire multiple images from the swapchain if we want:
If a swapchain has enough presentable images, applications can acquire multiple images without an intervening vkQueuePresentKHR. Applications can present images in a different order than the order in which they were acquired.
Using the conclusion above I just called vkAcquireNextImageKHR to get every image of the swapchain and changed layout on all of them at once. After that I presented all of them to get them into the system so to speak.
It seems to work in the sense that all images are handed to me by the swapchain, but then again, I found no guarantee that all of them can actually be acquired immediately after creating the swapchain.
Ok, embarrassing, there must be an easy way - I have a Core Data model diagram that I want to print - printing is easy, but it pushes it over 4 pages which is difficult to carry around as a handy reference - how do I get it to shrink it onto 1 page?
I defined a 1m by 1m paper size, used it to create a PDF, cropped and then printed it:
Go to "File"->"Page Setup…"
Go to "Paper Size"->"Manage Custom Sizes…"
Define a new paper size with 1000x1000 mm and no borders
Go to "File"->"Print…"
Choose "PDF"->"Open PDF in Preview"
Go to "Tools"->"Rectangular Selection", select the area to crop
Do "Tools"->"Crop"
Go to "File"->"Print…", print
Sounds complicated, but works. Instead of cropping, you could use the scale factor in the Preview print dialog.
I ran into the same problem described above, where the zoom didn't really seem to work well much below about 70-80%. I found that if (in XCode 4) you go to File->Page Setup, then choose a different size of paper that the model will fit onto 1 page (I chose A3). Then go to File->Print but instead of printing the document, choose "Save PDF". Then view the resulting PDF file using Preview, and print from there: Preview will allow you to scale the image in the Print dialog so that it fits on whatever size paper your printer supports.
I tried this in XCode 4 - as mentioned, there is a "Page Setup" with Zoom option - however it seems to be limited - any zoom level below 70% seems to produce inconsistent results: either it thinks that it now fits on a single page, but parts are cut off, or it doesn't actually decrease the zoom an further as you request smaller percentages....
It's a little counter-intuitive, but in XCode (4) whilst viewing your data model go to File->Page Setup, which will let you adjust the zoom level.
You can then go to print and check the zoom level is high enough to fit your diagram onto a single sheet.
And if you're not on Xcode 4, you have to resort to n-up printing in preview and copy-pasting (the involving scissors kind) the pages together. The support for page setup was lost somewhere around Xcode 3.1.
I'm making a Universal App using MonoTouch, and I'm adding my Default-Portrait.png file. That file alone (a 768x1004 .png file) is adding 711k to the size of the app. My app itself is only about 7 megs, so it's adding 10% just for the splash screen.
I could easily make this thing an 80k jpg file instead of a png, but the device doesn't seem to look for a .jpg file. Does anyone have tips for reducing the size of this launch art?
At this point, I'm thinking I might just leave the launch art out and load my own jpg and display it as soon as I have the ability to. That'll keep my app size down, but it's not as nice as having the launch art scale in immediately like most apps do.
Hmmm...given the screen of the iPad and the visual quality users are expecting, I'd just leave it like that.
But if you do want to reduce the disk space, try going to Project > Edit Project Settings > Build (tab at top), and searching for a parameter called "Compress PNG Files." Make sure that's checked. It'll run the pngcrush utility before loading the file onto disk (check the size of your IPA archive after to see if it had any effect).
pngcrush is nice as well, however that will not reduce the quality of you image. If reducing the quality of the image is an option for you, then you might try this tool: http://www.punypng.com/ - or just use an image editing tool to "optimize" the image ...
I recommend pngout if you want to really squeeze those PNGs down, and this won't cost you any quality. It simply removes unnecessary metadata (like pngcrush) and uses its own compression algorithm which is compatible with the regular decompressor used in PNG (zlib). It's really slow, though.
A simpler option is to try "Save for web" in your image manipulation program of choice. Exporting from Acorn (not just the regular save) sometimes gives me vastly smaller files. This is especially true for default images which have large, uniform areas in one colour (screenshots, a small logo in the middle of a black screen).
Is there any reason why you want to reduce the file size that badly? I don't think it matters in your case. I just checked 3 of my apps and the Default.png (of various portrait/landscape varieties) is between 29KB and 422KB, so whilst yours do seem a little heavy, your still way under the 3G download limit.
Are you positive it's adding that much to the size of the app? Did you compare a before and after?
Xcode uses pngcrush on the images for you. I know because I just tried to substitue jpegs for pngs and got the following result:
So, in short, there's not a lot to be done except simplify the image beforehand. Xcode will handle the rest.