The ozz-animation samples are also affected by this bug, and it looks like only the OSX Chrome Canary version has the problem. For instance:
http://guillaumeblanc.github.io/ozz-animation/samples/playback/ I only see a vertical line where the 3D skeleton should be rendered. I'm starting to get a bit worried about the lack of activity in the Chrome ticket: https://bugs.chromium.org/p/chromium/issues/detail?id=719866#c5 I hope the bug doesn't make it into the public Chrome version. Can anybody here reproduce this problem? (OSX, recent Chrome Canary)? Cheers, -Floh. Am Dienstag, 9. Mai 2017 10:11:44 UTC+2 schrieb Floh: > > Chrome ticket: > https://bugs.chromium.org/p/chromium/issues/detail?id=719866 > > Am Dienstag, 9. Mai 2017 10:00:13 UTC+2 schrieb Floh: >> >> Ok, please ignore the title, it's not in emscripten, it's the latest >> Chrome Canary. >> >> I was confused because the problem only happens when compiling with -O2 >> or -O3, not with -O0 or -O1. >> >> Chrome stable and Firefox don't have the problem. >> >> You can check yourself in this demo: >> http://floooh.github.io/oryol/asmjs/DebugText.html, in Chrome Canary, >> the characters are very small and in the top-left corner. >> >> I'll write a ticket on the Chrome bug tracker. >> >> Am Dienstag, 9. Mai 2017 00:06:10 UTC+2 schrieb Floh: >>> >>> Interestingly, the problem does *not* happen when compiling for >>> WebAssembly, it only happens in asm.js. The only difference is "-s WASM=1" >>> and "-s BINARYEN_METHOD="native-wasm"" in the linker stage. >>> >>> Am Montag, 8. Mai 2017 23:47:40 UTC+2 schrieb Floh: >>>> >>>> Hi, >>>> >>>> I just noticed a very strange regression after I upgraded to the latest >>>> incoming last Friday: >>>> >>>> Basically this fairly old code produces the wrong values for GlyphSize >>>> now: >>>> >>>> >>>> https://github.com/floooh/oryol/blob/master/code/Modules/Dbg/text/debugTextRenderer.cc#L133 >>>> >>>> It's not the glm::vec2 class or any alignment issue, the issue also >>>> happens when rewriting like this: >>>> >>>> const float w = 8.0f / Gfx::PassAttrs().FramebufferWidth >>>> const float glyphWidth = w * 4.0f; >>>> >>>> (FramebufferWidth is an int, usually 800, the 4.0f factor is from 2.0f >>>> * textScale (textScale being 2.0f)). The resulting glyphWidth is too small >>>> (0.0025f instead of 0.04f). >>>> >>>> Rewriting the expression to (32.0f / Gfx::PassAttrs().FramebufferWidth) >>>> works correctly. >>>> >>>> Compiling a native version in Xcode produces correct code. It must be a >>>> very recent emscripten regression (or clang 4.0?). >>>> >>>> Anybody seen similar problems after updating incoming? >>>> >>>> It's quite late now, I'll try to find out more tomorrow (do a fresh >>>> install from scratch, write isolated test case, do a bisect, etc...). >>>> >>>> Cheers, >>>> -Floh. >>>> >>>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
