I think it is unlikely that replacing the DLLs will work.
If internal data structure don’t match, things will crash.
And I expect Xojo to validate number to see if DLL matches to the headers they used.
Yep. 95.x is a bit old for the speed of hardware releases and updates.
Current stable one is 101.x, 102 is beta while I’m writing this.
There are hundreds of changes from 95 to 101, with lots of fixes, clean ups, and new APIs, as better a Canvas2D API in 99.x and better multi-monitor support for 100.x
Not sure if it will fix your problem, we will need to see, but it fix a lot of problems and potential problems.
Open a request of an update of the Xojo CEF to the latest stable one for the next release.
I like how Xojo 2022r1.1 ships with an embedded BETA version of Chromium from 7 months ago! Wow. Like it’s not even a stable release.
That’s incorrect, Xojo used the 95.x stable one 95.0.4638.69
You are pointing to the 95.0.4638.10
Phew. That’s at least a little better. BUT it’s still 7 months old!
The Feedback App is your friend.
I will, but I am still following your previous advice first! Remember? You asked me to sign up on the CEF forum and report the issue there. I did and I am now following their advice to test 2 standalone CEF releases so see if hardware acceleration is enabled or not. If it is in their standalone CEF releases and not when in Xojo, then EVERYTHING will be pointed towards Xojo not launching CEF correctly, missing a flag or something that makes those nVidia cards not be used. I will then reach out to Xojo with all the due diligence done, not like an imbecile who only points the finger at Xojo for no reason.
Don’t tell me not to follow advice now after what you wrote this morning for no apparent reason:
That’s a great advice.
…CEF standalone release 95.0 runs at 144fps and every single thing is hardware accelerated. So it’s DEFINITELY a CEF implementation issue from Xojo. It’s time for a little chat with the Xojo devs.
Copy the report. The full report. From Xojo and the standalone.
It will help to pinpoint the differences.
almost as if
“There’s no free lunch”
This has been an entertaining thread; also educational, and I’m feeling better about my decision a few years ago to stick with HTMLViewer’s native renderer instead of opting for CEF. That choice definiely had some pain, tweaking WebGL code to work under IE11 is not my idea of fun, but once finished, it works quite well. YMMV of course: in my case, I had 100% control over the JavaScript, HTML, CSS, and WebGL code, so getting it to run in IE11 was possible.
The answer to all of this is that we really need Xojo to natively support https://developer.microsoft.com/en-us/microsoft-edge/webview2/ which would give us the best of all worlds:
- a modern webkit-forked browser engine
- that is built into WindowsOS
- which means there are no 100MB+ overhead of DLLs etc.
- and the engine automatically receives updates
If you like this idea, please vote: <https://xojo.com/issue/59961>
The main issue is that you cannot remotely execute Javascript nor get values back from the web app that’s running in native mode. This can be a deal breaker for complex applications. As a matter of fact, popping up a native HTMLViewer is exactly the same as popping up a new tab in the user’s browser. It’s kind of pointless a little when you need to I/O DATA. I guess one could use a third app to connect the two, for instance PHP in a web server somewhere that would grab the DATA from the web app and then the Xojo app could connect to it and send/receive DATA.
I kind of agree on WebView2. I think it would be a better option for the Windows platform.
Your desire is a subject of another thread as it is not related to current thread.
CEF works all the time, when it does not, probably it’s a question of updating it. It has features WebView2 does not have and many of us need.
Except when it’s implemented dubiously by Xojo? I must admit that on my W7 PC (the one with the AMD Radeon graphics card) that I am EXTREMELY impressed by the performance of CEF and lack of issues (there are NONE). It exceeded my expectations.
You have all the data Xojo needs to fix your problem. Please, provide them with it and let’s wait for a better and updated version.
I am, please relax 
I am 
Counselor, though I agree, the OP has asked for futher clarification, so I will allow it 
Oh, I saw this earlier and meant to comment: this is not true. The native HTMLViewer has
HTMLViewer.ExecuteJavascript (js as String)
which works on mac and windows.
The problem is returning data from JavaScript to Xojo - there are a few solutions:
- using a MBS plugin
- returning data in Document.Title
- returning data by using a custom URL scheme, such as “mydata://” …
Not elegant, but functional.
(Edit): See https://www.mbs-plugins.de/archive/2020-05-23/HTMLViewer_JavaScript_communic/monkeybreadsoftware_blog_xojo
1 Like
But it does not have ExecuteJavascriptSync() so how do you get DATA back from the web app?
EDIT: Sorry, just saw the TITLE hack. Clever! Tough I wonder what is the max size of TITLE. In earlier HTML specs, I think it was 255 characters max and same for URL’s too. So you would have been F*cked if you wanted to return a paragraph of text or something. Not sure what it is nowadays, but I can’t possibly imagine it being more than like 1K.
Workarounds with limitations.
1 Like