Added section on simulating different resolutions

docs/en/manuals/adapting-graphics-to-screen-size.md

@@ -111,3 +111,10 @@ You can learn more about these properties [in the GUI manual](/manuals/gui/#_nod
 ### Layouts
 
 Defold supports GUIs that automatically adapt to screen orientation changes on mobile devices. By using this feature you can design a GUI that can adapt to the orientation and aspect ratio of a range of screen sizes. It is also possible to create layouts that match particular device models. You can learn more about this system in the [GUI Layouts manual](/manuals/gui-layouts/)
+
+
+## Testing different screen sizes
+
+The Debug menu contains an option to simulate the resolution of either a certain device model resolution or a custom resolution. While the application is running you can select <kbd>Debug->Simulate Resolution</kbd> and pick one of the device models from the list. The running application window will resize and you'll be able to see how your game looks in a different resolution or with a different aspect ratio.
+
+![](images/screen_size/simulate-resolution.png)

docs/en/manuals/optimization.md

@@ -16,11 +16,11 @@ It is important to understand the technical constraints of the platform(s) where
 
 Defold will create a dependency tree when building and bundling your application. The build system will start from the bootstrap collection specified in the *game.project* file and inspect every referenced collection, game object and component to build a list of the assets that are in use. It is only these assets that will get included in the final application bundle. Anything not directly referenced will get excluded. While it is good to know that unused assets will not be included you as a developer still needs to consider what goes into the final application and the size of the individual assets and the total size of the application bundle. Some target platforms and distribution channels have limitations on application size:
 
-* Apple and Google has defined application size limits when downloading over mobile networks (as opposed to downloading over Wifi)
-  * In the summer of 2019 these limits were 100 Mb for Google Play and 150 Mb for the Apple App Store
+* Apple and Google has defined application size limits when downloading over mobile networks (as opposed to downloading over Wifi).
+  * In the summer of 2019 these limits were 100 MB for Google Play and 150 MB for the Apple App Store.
 * Facebook has a recommendation that a Facebook Instant Game should start in less than 5 seconds and preferably less than 3 seconds.
-  * What this means for actual application size is not clearly defined but we are talking size in the range of around up to 20 Mb
-* Playable ads are usually limited to between 2 and 5 Mb depending on the ad network
+  * What this means for actual application size is not clearly defined but we are talking size in the range of up to 20 MB.
+* Playable ads are usually limited to between 2 and 5 MB depending on the ad network.
 
 To get a better understanding of what makes up the size of your application you can [generate a build report](/manuals/bundling/#_build_reports) when bundling. It is quite common that sounds and graphics is what takes up the bulk of the size of any game.
 
@@ -30,14 +30,14 @@ Defold supports .ogg and .wav files where .ogg is typically used for music and .
 
 ### Optimizing graphics
 
-You have several options when it comes to optimizing the graphics used by your game but the first thing to do is to check the size of the graphics that gets added to an atlas or used as a tilesource. You should never use a larger size on the graphics than is actually needed in your game. Importing large images and scaling them down to the appropriate size is a waste of texture memory and should be avoided. Start by adjusting the size of the images using external image editing software to the actual size needed in your game. Once you have the images down to the correct size and added to atlases or used in tilesources you also need to consider the size of the atlases themselves. The maximum atlas size that can be used varies between platforms and graphics hardware.
+You have several options when it comes to optimizing the graphics used by your game but the first thing to do is to check the size of the graphics that gets added to an atlas or used as a tilesource. You should never use a larger size on the graphics than is actually needed in your game. Importing large images and scaling them down to the appropriate size is a waste of texture memory and should be avoided. Start by adjusting the size of the images using external image editing software to the actual size needed in your game. For things such as background images it might also be ok to use a small image and scale it up to the desired size. Once you have the images down to the correct size and added to atlases or used in tilesources you also need to consider the size of the atlases themselves. The maximum atlas size that can be used varies between platforms and graphics hardware.
 
 ::: sidenote
 [This forum posts](https://forum.defold.com/t/texture-management-in-defold/8921/17?u=britzl) suggests several tips on how to resize multiple images using scripts or third party software.
 :::
 
 * Max texture size on HTML5: https://webglstats.com/webgl/parameter/MAX_TEXTURE_SIZE
-* Max texture size on iOS
+* Max texture size on iOS:
   * iPad: 2048x2048
   * iPhone 4: 2048x2048
   * iPad 2, 3, Mini, Air, Pro: 4096x4096

docs/en/manuals/optimizing.md

@@ -1,25 +0,0 @@
----
-title: Optimizing an application
-brief: This manual explains various ways to identify areas to optimize.
----
-
-# Introduction
-
-
-
-## Storage and run-time size of graphics
-
-It is important to always keep in mind the limitations of your target platform(s). On mobile devices it is especially important to keep an eye on the both application size and the size the images take up when loaded into memory. When you bundle your game you can also [generate a build report](/manuals/profiling/#_build_reports) containing a breakdown of content included in your application bundle. You can use this to inspect the size on disk and make decisions about reducing the size of certain images or applying image compression (and perhaps also compress audio which usually takes up quite a bit of space).
-
-![](images/profiling/build_report_html.png)
-
-For things such as background images it might for instance be ok to use a small image and scale it up to the desired size. This kind of image size optimization is done on the image before it is added to Defold in an atlas or a tilesource. Once the reduced size image is imported it can be scaled using the normal scale property of a game object or component depending on where it is supposed to be used.
-
-It can also be acceptable to apply compression on images to reduce both storage size and run-time memory usage. Defold supports automatic texture processing and compression of image data using something called texture profiles. The texture profiles match groups of files or individual files to different texture compression algorithms with an option to apply different compression algorithms based on the target platform. You can also use the texture profiles system to disable mipmaps for content that isn't scaled to save further storage space. You can read more about how to use this system in the [Texture Profiles manual](/manuals/texture-profiles/).
-
-
-## Reducing CPU usage
-
-## Reducing GPU usage
-
-## Reducing battery consumption