C3 Local Preview (Remote Preview Alternative)

Post reply
0 favourites
From the Asset Store
Falling shapes alternative
$9.99 USD
Template for an alternative to falling shapes, fully documented in comments and video
bartalluyn's avatar
bartalluyn

  • The ICE candidates are generated by and read by the browser, and the browser is what attempts the connection based on the information. As I mentioned Construct has no part in this particular process - its only job is to swap them between each device, which is what the signalling server does.

    However if you inspect the ICE candidate information that the browser generates, it may identify some leads.

  • Ashley we have continued to review the ICE candidates as we were before and have found an issue on some iPhones. Depending on Safari settings, Safari will or will not include the 'host' ICE Candidate. So, when the 'host' candidate is not available, in some cases C3 remote preview / webRTC will be forced to use a relay connection through a relay server (I guess this is turn.construct.net). Which will be slow.

    The fix is to make sure the following experimental setting is set on the iPhone:

    Settings->Safari->Advanced->Experimental features->WebRTC mDNS ICE candidates

    tarek2 Tested this fix on their iPhone 6 w/ iOS 12 and it works, now does fast downloads with C3 Remote.

    I have tested on my iPhone w/ iOS 13 and turning it off changes the behavior, but it still works fast (it does not do host, but does a prflx, which does work as host, so perhaps some differences between iOS versions also.)

    It may not be a universal fix, but at least good for at least one case.

  • Wow Thanks to Mikal yesterday we finally know the mystery of the iPhone6 why was super slow loading even when it was using Chrome 80.

    An important note is that the iPhone 6 it never loaded anything ever quick and its been like this since c3 come out three years ago, so for the first time, it loaded fast even testing a project of 32mb which normally would take me 7 to 9 min. I can't believe that it was just one setting to turn it on all this time.

    So it wasn't the iOS problem like I thought on this thread

    https://www.construct.net/en/forum/construct-3/general-discussion-7/preview-wi-fi-super-slow-146770

    And here is the prove:

    By just activating one feature "webRTC mDNS ICE candidates" the drastic loading Time is huge.

    I record both tests on the same video with the same C3 project 32mb.

    "webRTC mDNS ICE candidates" = ON >>>>>> 17 seconds

    "webRTC mDNS ICE candidates" = OFF >>>>>> 6 minutes

    C3 Project that I tested: is the same that I been posting

    dropbox.com/s/px780oole0wwdj2/c3_local_preview_test.c3p

    Here is the video:

    dropbox.com/s/us3py0s9nneejgp/c3%20slow%20preview%20%28canditate%20off-on%29-1.m4v

    =====================================================

    Now the question is why it keeps happening some times on Phones that already have that "webRTC mDNS ICE candidates" = ON like my iPhone 7, 8, Xs Max etc...

    We have been looking yesterday Mikal and I at safari debug iPhone 6 and it looks like the similar thing happen as when you have "webRTC mDNS ICE candidates" = OFF

    Which it Picks the Wrong Candidate that's why it ends on slow loadings as you see on the video when the "webRTC mDNS ICE candidates" = its OFF

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I had got the impression this problem occurred on all mobile devices, not just iOS, since the thread didn't specify it only happened on iOS (or did I miss that?)

    If it only happened on iOS, and that fixes it, then that's great! I guess mDNS helps establish local connections. Generally those experimental options eventually graduate to enabled-by-default, so hopefully that will just work out of the box in future.

  • I had got the impression this problem occurred on all mobile devices, not just iOS, since the thread didn't specify it only happened on iOS (or did I miss that?)

    If it only happened on iOS, and that fixes it, then that's great! I guess mDNS helps establish local connections. Generally those experimental options eventually graduate to enabled-by-default, so hopefully that will just work out of the box in future.

    Ashley

    I think it been a misunderstanding, what was fix it's that if you don't activate that feature "webRTC mDNS ICE candidates" then C3 Remote Preview it will never work as it happened with my iPhone6 for over three years it was OFF.

    But Activating "webRTC mDNS ICE candidates" doesn't mean that C3 Remote Preview is gonna load fast all the Time because my other Phones all them had the "webRTC mDNS ICE candidates" =On all the time

    So there are still some problems to resolve for C3 Remote Preview to load fast all the Time, we believe wen Chrome makes the connections it chooses the wrong "Candidates" making C3 load slow and this happens even when "webRTC mDNS ICE candidates" it's ON, it's like 50/50, fifty fast and fifty slow, it depends on the day.

    Also, the thread is not only about iOS as we don't know what the other users which pones they have that reported slow Preview loadings, but I also don't believe we all have iOS if I'm not mistaking.

    But you see only iOS mentioned on this thread because it's only me and Mikal making debugging and reporting back and he uses iOS for testing and I'm using iOS too, so maybe that's why you see all the time speak about iOS.

    Will be nice if anyone that have problems with other phones like Android could report here so we can find a solution once for all, They where many that reported slow loading and voted for C3 local preview also but not sure which phones they have Android? iPhone?

    If they could share their experiences will be grate.

  • Chrome has a flag for mDNS in chrome://flags too. I'm not sure if it's on or off by default, but switching that to "On" might help too.

  • Thanks for the further investigations - I did play with this flag before and it didn't seem to impact which iceCandidate pair was chosen, it just changed the listed ICE candidate local 'host' type IP address from a 'dot' number to an obfuscated string ending in .local (as is the intention of the spec.)

    That being said, it has been useful for debug - to reveal the actual IP address chosen, rather than the obfuscated string address.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)