Solution: HTML5 canvas 1:1 pixel ratio

For HTML5 target, I wanted to have stage stretched fully across browser window and have pixels resolution exactly 1:1, ignoring user’s browser zoom level, so I came up with this solution:

in project.xml:

<window width="1024" height="768" fps="60" /> 
<window width="0" height="0" if="html5" /> 

in html5/bin/index.html, replace default lime.embed(…) line with this JS code (probably make copy of this file as index2.html):

 var r = window.devicePixelRatio;
var w = Math.round(window.innerWidth * r);
var h = Math.round(window.innerHeight * r);

var c = document.getElementById('openfl-content'); = w + 'px'; = h + 'px'; = 'scale('+(1/r)+','+(1/r)+')'; = '0 0';
    lime.embed ("openfl-content", w, h, "FFFFFF");

in Main.hx, currently this code is not mandatory, but maybe for future OpenFL releases this might have positive effect:

   stage.scaleMode = StageScaleMode.NO_SCALE;
   stage.align = StageAlign.TOP_LEFT; 

todo: auto resize stage when browser window gets resized

1 Like

Perhaps we could consider supporting more scale modes, that’s a cool solution, though – and it works properly with events? I tried to design the HTML5 target to accept the element it was given, so that you could constrain the project to as small or large an area you want.

Do you mind if I ask an unrelated question that’s been on my mind? It would be possible for us to compile an “openfl.js” file, that included the full API, then compile applications to work against it. It would allow for heavier minification, as well sharing or caching of the openfl.js file, in the case of multiple projects on the same site or page.

Do you think that would be a good idea, or do you like how it is working now, or does it not matter?

I’ll develop my app further and later I can confirm about resize event handling or post any issues I encounter regarding this thing.

Yes, no problem. This separation of API code out of app.js file I see as pure performance improvement, from other viewpoints it does not matter. Generally, in projects roadmap, I personally try to push such issues in later stages, because functionality and stability/bugs usually are more important than performance polishments.

This view comes from my little design strategy for anything:

  1. first, quick’n’dirty, bruteforce coding/algorithm; job should be done with desired results
  2. refactoring for cleaner code, data structures and API
  3. stability / bugs
  4. performance is last, and even then, only when pops up in the eyes - I mean, visible performance deficiencies are in priority

This topic much close for what I’m need, so I ask here.

Is there a fast way to set fixed size for html5-canvas target with project.xml file? I manually setting the size in pixels inside index.html (change width and height props for body style) each time after compiling my project. Of course I can do something like post-build command which replace new-html file by old-html with needed style props, but I’d like to do this by simple editing project.xml.

You can override your HTML page using <template path="templates" /> in your project, then defining “templates/html5/template/index.html” (I believe) as your own file, which will be used instead of the Lime or OpenFL file template when testing your project.

The HTML5 target is designed to resize relative to it’s native resolution (set in project.xml) and the actual DIV size on the page.

Maybe this is outdated and it is already possible to do it, but having the project being split into openfl.js and project_code.js would be great!

Although not that big when minified, it would still help on the caching process.

Is there any way to actually do this now?

There is something called “gen hx classes” that I honk can make externs automatically

I think he idea would be to compile to JavaScript using something like “ImportAll” class under openfl/docs to compile all the classes. Theoretically, we could also test more vigorous minification, but that could be done later

In addition, we would use something like the gen hx classes for externs. When compiling your project, you would use these instead of the original Haxe source files, so the OpenFL code is not built into your file

If we could get this working in isolation, it would be easier to look at automating it. Maybe worth checking out?