I wrote that my laptop is rendering using webgl, so my graphic card is supported
I always make tests on vanilla Chrome, with no plugins and one tab, with no other program like Unity or Blender running. This time I close antivir, and nothing happen. Same scenerio on second machine with different graphics, cpu.
Link to capx file is in first post in topic.
I checked timeline, and only thing I saw was "long frames" every 1-2 seconds, so there is some jank [#sherlock].
I also tried old fashion restart and check(http://gamedev.stackexchange.com/questi ... -4-seconds), and it did nothing much- drops happen less, but objects are still stuttering
I recently noticed a 1 sec jank in the simple layout I'm testing (uses a large tilemap) but this only happened when the layout was zoomed out and the whole tilemap was being rendered. I only meant my previous post as banter rather than for it to be a criticism of your testing etc.
It may still be a bug with vsync and the browser on your device. Maybe something along the lines of this bug:
https://bugs.chromium.org/p/chromium/is ... ?id=422000
It references this site to test the vsync of your browser. If frames are never dropped the word "vsync" should look grey, otherwise it will flicker.
Yes, I noticed some flickering.
According to the preformance graph in test of vsync of my browser, my average inter-frame millisecond time is 17.056. Every second moving picture stops and there is heap on chart out of scale.
I read the article about the VSYNC synchronization test, and the "bug" in chrome 38+ ... it's really frightening.
"Under Windows, Chrome 38+, Firefox 32+, and Internet Explorer DO NOT properly synchronize rendered frames to a display's VSYNC refresh signal".
Honestly, I did not expect that something like this could have happen. How is it possible?
Also, it looks like it is insoluble problem. Please, tell me I'm wrong.
Is the hardware in your chrome even enabled ?
For me it looks like this:
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
All Hardware is enabled. Native GpuMemoryBuffers is no issue on Windows.
How is this test running for you ?
http://www.testufo.com/#test=framerates ... s&pps=2880
Also click and move the mouse during the test.
(here it runs fine on all test modi, see the dropdown menu's)
Maybe it would be an idea to make this stuff into some kind of poll. I am curious for everyones perfomance in a browser.
With all tests I got "SYNC FAILURE: Imperfect sync. Try closing all apps and browser tabs. " - with one tab opened on clean Chrome v50.
Now, after that long conversation (thank you everyone), I know that VSync can be serious problem- some people have it (or something similar), some don't (or don't know about it yet), some people pay attention to it (because of personal perseption), and some don't (they do not see this as an error, or do not see at all). It's not easy to find main reason of that problem, and it's hard to prove. But first of all - it's sad, that vsync-problem exist.. at all.
I tried to make test on some other machines I had access to. All with different software and hardware configuration- all of them had some vsync issues. Also I read about some bizarre tricks to make browser work a little differently.. yea, but what for - average player know nothing about vsync types, chrome flags and others.
I am quite abashed - Now I know my current situation is the result of vsync-related-problem, but also I still cannot understand part of platform behavior code in all of it, there is collision detection load part of course, however those frame drops are disproportionately larg, so maybe there is something more,waiting to be discovered...
Do anyone experiance something similar? What can I do to make my games more accessible on web browser? What tools should I use to execute optimalization tests on device with vsync problem? How to messure game performance in such situation? How can I know if bad performance is my fault, or runtime environment?
( Maybe I should change topic title to make it more accessible for others ? )
You have a serious problem. I am sorry to have no solution.
Closing as not a bug. I think this is just what R0J0hound described: if the behavior is disabled it does nothing so the runtime doesn't even redraw the game, so everything looks faster because it's not actually doing anything at all (a variation of the "my game goes slower when a sprite starts moving, why is moving a sprite so slow" type of report we've had in the past).
I guess it's a minor problem a non-moving enabled platform behavior causes redraws, but I don't think it's a serious problem. The platform behavior is also very complex and has to do a lot of stuff like checking for moving platforms, slopes, gravity direction etc. so some of that could be triggering the redraw.
Still, there is no evidence this is a breakage, it looks like C2 has always worked like this. As somebody actually proved there have been no significant changes to the platform behavior. So there is nothing new here, it's just reporting the way things have always been.
If you have trouble with v-sync accuracy, that is an entirely different issue and depends on the browser code. You should probably file a bug at crbug.com with your system spec and v-sync stats to get that investigated, probably referencing crbug.com/422000 (the main vsync bug).
Develop games in your browser. Powerful, performant & highly capable.
Thank you for answer.
After investigation, and checking many things I realised platform behavior is not the main cause of my problem and there are many components and factors that can affect on all development process. Certainly, I make many mistakes during game/project assembling.
You said "it's just reporting the way things have always been". Ok I can understand that, and just want to focus attention on this issue. Maybe it's time to get into it and rewrite legacy code.
Also, I would like to thank everyone who took part in the discussion.
If i may add one more thing.
When i made this example for the forum ... i noticed that it in 'debugging' runs at unbearable framerates. While it runs perfect and smooth outside the 'debugger'. I know that the code is not that optimized, its just a quick example.
So i really think that one should not be botherd by 'debugger framerates'.
For future reference.
For future reference.