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 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');
c.style.width = w + 'px';
c.style.height = h + 'px';
c.style.transform = 'scale('+(1/r)+','+(1/r)+')';
c.style.transformOrigin = '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:
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:
first, quick’n’dirty, bruteforce coding/algorithm; job should be done with desired results
refactoring for cleaner code, data structures and API
stability / bugs
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.
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?
