The app was showing alright on lower resolution. But on higher resolution this code causes the app to scale thus showing only a part of it. The right and lower part gets clipped.
I could sort it out only by disabling this code.
if (typeof window.devicePixelRatio != 'undefined' && window.devicePixelRatio > 2) {
var meta = document.getElementById ("viewport");
meta.setAttribute ('content', 'width=device-width, initial-scale=' + (2 / window.devicePixelRatio) + ', user-scalable=no');
}
You can set up custom templates to modify what is generated in the output. The code generating the index file can be found here: openfl/assets/templates/html5/template/index.html at 5156f8c44edc831f0fa44cd74d86ab722c3084a8 · openfl/openfl · GitHub
To change this, create a copy of the index.html file above and make any modifications you’d like.
Next, create the following folder structure in your project root directory: custom-templates/html5/template, placing the new index.html file in the template folder. The final structure should be:
custom-templates/html5/template/index.html
Note: You can use any name you like for the main folder; it does not have to be custom-templates.
Finally, add the following code to your project.xml file to enable custom templates:
<template path="custom-templates" />
The next time you compile to HTML5, it will use your new index.html instead of the default version.
And here’s a sample project that contains a custom index.html template file:
I know about making template. But I just wanted to log the issue, as it’s sometimes difficult to figure out the root of such specific problem, especially when the part of code comes with the API itself. Eg. initially I was reluctant to disable that part thinking it could probably trigger some other rendering issue.
From my experience I can tell you that I always left out that bit of code from my HTML5 templates.
Beside from being useless, as the initial-scale should always be 1.0 in the case of a single canvas
covering the whole screen, it actually renders the canvas at the wrong resolution if the devicePixelRatio
of the target device is indeed higher than 2.
Say we have a project.xml including:
<window width="0" height="0" resizable="false" fps="60" if="html5" />
<window allow-high-dpi="true" />
<haxedef name="openfl_dpi_aware" />
and run something simple like:
package;
import openfl.display.Sprite;
import openfl.Lib;
class Main extends Sprite
{
public function new()
{
super();
}
}
on a 1280x720 device with a devicePixelRatio of 3, it creates a canvas of 5760x3240
instead of 3840x2160.
Yes. Something similar happened to me.
It was just one of my devices with a higher dpi the canvas was not rendering properly.
Took me many hours to figure it out.
Same here. I was running into performance issues on high DPI devices and wondered we’re the strange resolution values come from until I discovered that <meta> tag in the template.
Ok. I will try it. It’s different from the plain index-html file I use. I never used variables inside index.html eg.
<title>::APP_TITLE::</title>
But again as you see I can see the same java script code there too.
That’s to be expected. The point of the example is not to remove that code. It’s to show you how to create a custom template. Your custom template can remove that code.
@joshtynjala Just to emphasize this a little, from my findings
is clearly non-sense, as on a >2 DPR device, it renders stuff at a higher than the available resolution, as it divides the native resolution by 2 / window.devicePixelRatio e.g. in my example above
3840 / (2 / 3) = 3840 / 0.666666667 = 5760
Apparently, that scaling code has been in the index.html template since 2014 when that file was first added to the OpenFL repo. Unfortunately, there’s no explanation in the commit about why it was deemed necessary.
I never really thought deeply about what it was doing. My assumption was that it was there to limit the canvas size from getting too high and causing performance issues. Especially considering that many devices back then were not as powerful as they are today. However, if it actually increases the canvas resolution higher than necessary instead, that’s pretty strange, because that would hurt performance with no apparent benefit. I wonder if it was simply a misunderstanding of how scale affected the canvas size, and the author got it backwards.
Removing that code entirely may not necessarily be the correct solution. We may still want width=device-width and user-scalable=no, for instance.
Ideally, if we still wanted to keep some of it, the JS could be replaced entirely with an actual HTML tag:
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no"/>
This will require some testing on various devices with a variety of pixel ratios.
Yes. That’s one reason to log it here. To get more inputs and make sure if it’s ok to disable the code. And there is no side effect of disabling it.