Why this initial-scale change exists in index.html template?

What is the reason for this code in index.html template in Lime (lime/templates/html5/template/index.html at develop · openfl/lime · GitHub) that changes initial-scale of the viewport if the device pixel ratio is greater than 2?

		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');
		}

This causes the games running in a Telegram Mini App to scale in a wrong way for me on Android phones with high pixel ratio (in my case it was 2.625), like this:

But if you enable debugging and change initial-scale to 1 in the elements inspector, it becomes good:

By the way, the same game works fine in Chrome on the same phone!

I don’t understand the native code of “HTML”, but I can see the difference between the two screenshots you provided ..

I don’t understand the native code of “HTML”, but I can see the difference between the two screenshots you provided ..

Good to hear. The screenshots are different, indeed :)))

If you don’t like the default template, you can actually create a custom index.html template to use instead of the default one.

I created a sample project that shows how to do it:

1 Like

Thanks, Josh!

I do use custom templates sometimes, actually in this case I just inserted a JavaScript code (with js.Syntax.code) that force sets initial-scale to 1.

But I believe it is set in the template like this for a reason. And I’m curious what the reason is :slight_smile:

I have never figured out exactly why that code is there. It’s certainly something I plan to look at more deeply when I have the time. I suspect that we will possibly remove it because it has some pretty serious downsides. Not just aesthetic issues either. At very high pixel ratios, it renders at a much higher resolution than it needs to, which can lead to memory and performance issues.

Some quick investigation led me to the following commit, which shows that this code has been in Lime since Joshua seems to have started work on the html5 target in Lime version 2.0.0 in 2014.

1 Like

I found my previous investigation of this code. It looks like it was actually added to OpenFL a bit earlier, and it must have been copied into Lime.

From my side, I can add my two cents: right after the mentioned topic, we removed this piece of code from custom template and deployed the change to production with ~25k DAU. The issue with Telegram Apps (and, as far as I remember, Facebook Instant Games as well) was resolved. No negative side effects were discovered after the removal.

2 Likes

I found another related topic too btw )

Cool, but was the same app available as a standalone HTML5 app too? I mean, may this change cause issues in the browser games that work as is or in iFrame etc.?

This is why I wanted to know the reason for having this code in the template

Omg it’s exactly the same issue that I was trying to address the past 2 days (not full time tho) and I googled different stuff, but not this one!

Shame on you, Google!

This topic actually has a lot of info that I wanted to have, thanks :slight_smile:

2 Likes

The app works perfectly fine in an iFrame in VK and Facebook Instant Games (desktop and mobile browser versions). No changes or issues have been observed.

1 Like