Can't make python calls not block the UI

[Aric WithanA]

Good day!

I've tried out all the samples, I've researched and I've done so many trial and errors I'm at my wits end so might as well ask to see if it this is just futile.

I've been working on a nice little project to create an application environment for my LCARS SDK.  Currently I have CEF rendering to the desktop layer so that the view is always below other windows (Windows OS atm only).  Everything works perfect, the app so far is running and looking beautiful until I start calling Python functions.  

Not a single one of the framework samples worked for creating async python calls from javascript.  Even my own setup, which I created just using pywin32, click a button a dozen times to simply return a preset 'test string' back to the webview and the UI essentially locks up till it is done. It isn't a total loc, it is a bit of sputtering and then is fine once the string is returned. I've tried out all the different options I could find here and around the internet and nothing works.  

Am I missing something essential and nothing in the docs or samples are providing?  Is this just not possible and async calls to python are always going to block the ui?  I know Panda3d doesn't have this issue but it utilizes its own task manager and I really don't want users having to load up an entire 3d engine just to use a webview for async python calls.

I can provide code samples if requested.  The project will be open source in the end anyway. 

-Aricwithana

[Czarek Tomczak]

Python <> Javascript calls are asynchronus, use IPC messaging between processes. The behavior you're having is not something I have experienced. What CEF Python version? The wxpython.py example provides lots of tests including js<>py calls, have you tested it with that example?

[Aric WithanA]

Well good to know that it is supposed to work so it must be on my end.

I'm at the most current version available via the pip install which looks, according to the read me, the same version as the windows download via dropbox/google drive. 

I've tested with the wxpython.py file by simply placing a CSS animation on the body to change its color every 100ms, which works fine.  Click on any of the js bindings demos and the animation stops as the python does its thing (which can be tracked in the console) and as soon as it is done and passes back the information for the alert popup, the animation begins again.  If you click quick multiple times before the python can return and do the js alert, it will block any alerts till the last event triggered was processed and then you get a stack of alerts.

Here is a video desktop capture to make things easier to see:

https://drive.google.com/file/d/0B3JkqeN568s8MGNOQ3BjN3pJVzg/view

I've edited nothing other than adding the css and a body class to the html.

I hate to bother devs so I used this as my last resort after not being able to make things work.  

[Czarek Tomczak]

I suspect this might have something to do with Python's GIL. Your video with CSS animation shows the issue very clearly.

Below you can see that GIL is being released when calling CEF's message loop work using the "with nogil" statement. There is also a comment stating that otherwise you would get a dead lock when calling from c++ to python: https://github.com/cztomczak/cefpython/blob/cefpython54/src/cefpython.pyx#L829

I must say I don't know much on GIL, would need to do more reading. Here is some reading from Cython's documentation:

Note that acquiring the GIL is a blocking thread-synchronising operation, and therefore potentially costly. It might not be worth releasing the GIL for minor calculations. Usually, I/O operations and substantial computations in parallel code will benefit from it.

Each call from Javascript to Python must acquire the GIL. But I just can't believe that it is such time costly as your video shows.

You were saying that this was also occuring with pywin32. Were you calling MessageLoop() in that case as in the official pywin32 example? The wxpython.py example is using MessageLoopWork(). I wonder if MessageLoop vs MessageLoopWork makes any difference for this issue.

[Czarek Tomczak]

One more thing on my mind. There is an alternative for js<>py communication, from README.md:

For native communication between javascript and python use javascript bindings. Another option is to run an internal python web server and use websockets/XMLHttpRequest for js<>python communication.

Using web server and XHR for communication wouldn't require any acquiring/releasing GIL, thus the issue should disappear I think. Have you tried that?

[Aric WithanA]

I'm using the MessageLoop with the pywin32.  I had my fingers crossed that wx would have solved the problem since I didn't utilize it since I was already used to working with win32 calls from other prototype testings with other frameworks.

I'm not much for backend coding and my python, while getting stronger is less than my web dev skills.  I don't really know anything about GIL but everything else has worked perfect.  If we can figure out this ui blocking issue that is happening, I can fully commit to cefPython since replacing the linux desktop should be even easier and that is my next step after Windows.

Attached the py file just so it is easier for you.  Its essentially the py32 example with just some minor modifications to where the cef window renders and added the js bindings (which work fine other than they are blocking).

[Aric WithanA]

I have not because my python knowledge hasn't gotten far enough to do such a thing and it was an added layer for others to work with when making their own apps for the environment.  If it is in the end the only real option, then that is what I'll go with but I'm hoping not for at the moment.  I could utilize a webserver setup like that to allow different computers running the app or a mobile devices to interact and such.  It was something I considered way back for functionality but set it in the 'future' pile for a feature.

[Czarek Tomczak]

I have created Issue #277 that describes the problem in great details. At the end of the post I have described a possible real solution, however the issue seem to be complex and I wouldn't count on it being fixed soon.

[Aric WithanA]

Thanks a bunch! I've subscribed tot he git thread for any updates and if I figure anything out I'll post there too.  

cefPython is pretty much my only option, especially since I want to move into the arm area with rPi devices and such.  Could you let me know if this happens on the newer versions for Linux?  I have more than a few linux users and linux is the obvious for the rPi or other ARM based boards.

Just strange that others use this and not have really said a word in all this time.  They must have just used the webserver aspect and moved on so I'll dig into that deeper, lol

[Czarek Tomczak]

Added time measurement in unit tests and the issue doesn't reproduce on Linux in v54. The time it takes to execute Python function and then back js callback is just 11 ms. Commit: https://github.com/cztomczak/cefpython/commit/6ffb865c0a95346e9343832ec4405f3591ce7ab8

Whether this is an issue with old CEF Python, or Windows only issue, or an issue with your OS/Python configuration, no idea.

[Aric WithanA]

I'll spin up an ubuntu vm here today and test out the most recent stuff and see if the 11ms stacks if you click multiple times and I'll put a delay in the python call back too to see if that holds things off too.  I'm one step away from having a fully working 'active desktop' replacement for windows and a full environment for functional LCARS so I'm not going to give up, my SDK demands it.  haha

[Czarek Tomczak]

Putting delay/sleep in main UI thread will obviously lock it, as in any GUI.

[Czarek Tomczak]

By default CEF runs message loop on main UI thread. On Windows you can use ApplicationSettings.multi_threaded_message_loop to run loop in a separate thread, however this wasn't yet tested with CEF Python.

[Aric WithanA]

Yea that doesn't work since the CreateBrowser isn't ported yet you mentioned in the docs.  It was one of the first things I tried to do.  I tried the PostTask but that failed to to prevent the blocking.  I just wish I new how everyone else got past this issue since your awesome framework has been out for some time now if they didn't use  a webserver.  Ubuntu is installing now so once that is done i"ll get things all setup and see what I come up with.  

[Czarek Tomczak]

I don't know how other Python GUI frameworks do it, but GIL in Python allows execution of only one native thread at a time. Thus if you run a second thread the main UI thread is suspended, meaning its message loop doesn't get called, thus GUI gets locked. This explains why PostTask failed. There is lots of discussion on web about why GIL sucks.

[Czarek Tomczak]

PostTask is for running on native threads. You should be fine running without UI locked on a Python thread I think, use the multithreading module.

[Aric WithanA]

Well good news for you and bad news for me.

Good news is that after getting everything installed in the vm and using the hello_world.py for the most recent version of cefPython everything works as it should.  The only thing I did was in the hello_world.py was add the js bindings and update the file path for the html.  It loaded up my window manager and lockscreen perfectly and the events, no UI blocking.  I can click as fast as I want and it never blocks like in the video.

I'm going to do a clean install again with linux and use the the older cef31 that I current have to use on windows and see if it reproduced.  If it doesn't then we know it is just a windows problem and I'll update git with all this information for the future!

[Czarek Tomczak]

If it turns out this is a Windows-only problem, then I think that there is an alternative solution, to use ApplicationSettings.multi_threaded_message_loop. Message loop will run in a separate thread and any calls to Python won't block UI. However whether this would also resolve issue with GIL acquiring lock taking much time, I don't know, but for sure it won't lock UI (css animation). I haven't yet played with multi threaded message loop, so don't know how this would affect current code base. There may be some issues that would need to be resolved.

[Aric WithanA]

I wasn't able to reproduce the issue on the 31.2 version of cefPython on Ubuntu so it looks to be a Windows specific issue.  So when I start doing rPi stuff or desktop linux things will work great!  

When working with the multi_threaded setting, yea it doesn't work quite right unless I'm missing something.  Seems to require CreateBrowser which hasn't been ported yet?  

[Czarek Tomczak]

When using multi threaded message loop I think you should be able to call CreateBrowserSync using PostTask(TID_UI). Tasks related to multi threaded message loop are to be implemented in Issue #137.

[Aric WithanA]

Yea I've tried multiple ways to use the setting.  The docs say not to use either of the message loops but if I do that then the browser never creates since the context isn't valid when using the post task.

I understand too with this version being older and you're moving ahead with the newer it isn't something that really needs time and energy to try and fix, especially since this isn't a paying job for ya.  I can just work with the linux version using pure cefPython and just use panda3d for windows for now.  Hopefully later on the newer windows version will have the CreateBrowser ported or your Solution #2 on git if you hit your donation goal.  

If I had the money laying around I'd drop it all for ya if it included a fix for this issue if I wasn't a poor dev, haha.

[Czarek Tomczak]

:-) So it will work for you for now, good.

Yea I've tried multiple ways to use the setting.  The docs say not to use either of the message loops but if I do that then the browser never creates since the context isn't valid when using the post task.

What do you mean by context? Is there an error message in logs saying that CreateBrowserSync failed?

[Aric WithanA]

Yep, I'm happy things at least work with Linux as they should.  Got a lot of linux users it seems from public and private chats and with the rPi and other arm-linux devices the future plans for the environment are stable.

Attached are three screenshots of the code and the log together the different ways I attempted to use the post task.  Hopefully I'm just doing something completely wrong, lol

[Czarek Tomczak]

You are doing it wrong. Post task runs asynchronously and returns immediately, and you call Shutdown just after it. You are shutting down CEF and then try to create browser... You can't because it was shut down.

[Aric WithanA]

No matter which way I place the code (I'm good at brute force combinations to find the right one when learning).  I tried it out in each of the combinations in that last image and while the context error goes away when removing the shutdown afterwards and putting it in something to call when the app closes:

[pywin32.py] pywin32 version = 220

[CEF Python] Initialize() called

[CEF Python] CefExecuteProcess(): exitCode = -1

[CEF Python] CefInitialize()

[CEF Python] App_OnBeforeCommandLineProcessing_BrowserProcess()

[CEF Python] Command line string for the browser process: "D:\Git\LCARS-NV\\Python27\python.exe" --browser-subprocess-path="D:\Git\LCARS-NV\Python27\lib\site-packages\cefpython3/subprocess" --lang=en-US --log-file="D:\Git\LCARS-NV\debug.log" --log-severity=info --enable-release-dcheck --resources-dir-path="D:\Git\LCARS-NV\Python27\lib\site-packages\cefpython3" --locales-dir-path="D:\Git\LCARS-NV\Python27\lib\site-packages\cefpython3/locales" --remote-debugging-port=50127 --no-sandbox "D:\Git\LCARS-NV\\LCARSNV.py"

[CEF Python] BrowserProcessHandler_OnBeforeChildProcessLaunch()

I can get things to work if I add a threading.timer with a MessageLoopWork in a def but still is ui blocking and the docs say I shouldn't be using that.

[Czarek Tomczak]

Every GUI app needs to run a message loop. When using multi threaded message loop you don't call CEF's message loop, but your app still need to run a message loop. Google "pywin32 message loop", win32gui.PumpMessages is probably what you need.

[Czarek Tomczak]

But don't call message loop on CEF's UI thread when using multi threaded... This goes beyond CEF Python support, good luck.

[Aric WithanA]

I've been giving that a whirl but not much success.  I've sent a callout to my followers to see if anyone with the skills can help out so we'll see. 

Nice thing is I did find out that the callback to JS from python doesn't block the UI, it is just the initial event telling python to call one of its defs from JS that is blocking.  So for now I can work around my limited python needs to setup data streaming for the main view app that will load in the environment and only have to call things once at startup and not again (I want system data streaming to fill in some LCARS eyecandy).

Thanks a huge bunch for all your help and the awesome framework.  Hopefully once you've been donated enough and port the new to windows you'll put in the fix to squash this issue once and for all, lol.

[Aric WithanA]

I should say, not much success to prevent the blocking!  The message loop with pywin worked perfect, lol  Does seem like the blocking is less when using the pywin message loop, it doesn't block for as long though it seems.

[Czarek Tomczak]

Nice thing is I did find out that the callback to JS from python doesn't block the UI, it is just the initial event telling python to call one of its defs from JS that is blocking.

Even though CEF's multi threaded message loop runs on a separate thread, it depends on native message loop running on pywin32 app's main thread. And that thread is locked because of GIL being acquired when calling from C++.

Can you do some debugging and measure the time it takes to execute Python function from javascript on Windows vs Linux with CEF Python v31? I would take this data and ask on the CEF Forum why would locking threads be so expensive in Chromium/CEF on Windows and whether something can be done about it. I have hard time believing that it is locking threads so costly on Windows in general, it might be that locking Chromium's threads is costly, but why.

If you have time it would be nice to do some extended debugging:
1. Make all tests for two cases: multi threaded message loop vs default message loop
2. For both cases test on Linux vs Windows
3. Test execution time for: Calling Python function from javascript in four cases 1) + 2)
4. Test execution time for: Calling Javascript callback from Python in four cases 1) + 2)
(you could just print time in milliseconds in javascript through html and python in console and then gather it and do substraction manually and you should acquire the data quite fast)

Currently I see that the final solution would be to use to use both solutions described in the Issue in the tracker: multi threaded message loop + Python-native IPC messaging with the renderer processes, without the Chromium/CEF IPC layer so that GIL doesn't need to be acquired when receiving messages.

[Czarek Tomczak]

Correction: As Linux doesn't support multi threaded it will be 3 cases: Linux vs Windows vs Windows multi threaded + two tests each = 6 tests in total.

[Aric WithanA]

Sure sure!  Give me a couple days, going to be swamped with work for the next couple starting today but I'll run the tests no problem, more than happy to help.  I wish I could help more, like actual coding to help fix it but I'll do what I can!

[Aric WithanA]

Sorry it took me longer to get to things!

Attached is the logs, I added spacing and such for easier reading to show off the numbers.  

For linux, yea all was good.  Only like 10ms max, and even while thinking the UI is not blocked.

Windows it seems to be cumulative and then steadies out around 500/600ms and blocks the UI.

So for the moment since I can do things without the need for python logic and just do all the current apps and eyecandy only with webtech.

[Czarek Tomczak]

Here are debug times on Windows from an another user: https://groups.google.com/d/msg/cefpython/mwSa7He90xA/0FCbILs-DQAJ
His times seem OK, on average 15ms.

Have you tested your app on a different computer? Try closing all applications and all unnecessary background processes in Task Manager, especially terminate any Security/Anti-Virus software, as these sometimes inject its own code into applications and that may cause issues.

[Aric WithanA]

Yea I've got a good friend that is a Python Wizard and he ran into the same issues when we were trying to work on a project using cefpython.  Nothing odd or anti-virus with the PC here  I can boot up a windows VM and do a quick test on there and see if I get anything different.

[Aric WithanA]

Evening!

Well I got around to doing some more testing and come to find out the issue is specifically Windows 10!

Same files, same setup on Windows 7, all works perfect as we'd think, even without multi-loop, just like on linux.  Same files, same setup on Windows 10, boom, UI blocking occurs.

So while I'm not sure what I can test further for you, at least this should help narrow things down!

-Aric

[Aric WithanA]

Hey Hey!

Finally had a moment to test things out.

Newest updates have loaded up the webview nicely, even if it is really slow doing so and spits a lot of stuff into the log.  The CSS animations are moving like butter.

The blocking issue is still happening though on Windows 10.  I'll be loading up some VMs here in the next few days to test out in linux and windows 7.  I'm going to wager all will be fine and this is just an issue with Windows 10.

Thanks for all the hard work!!!  The newest versions are just awesome and as a front end dev/designer it is so relaxing being able to do things up and not have to worry about legacy issues.

-Aric

[Czarek Tomczak]

If you can, try testing on some other Windows 10 machine.

[Aric WithanA]

Will do!  The last Windows 10 Testing included my actual machine and then two VM's, 32bit and 64bit.  I'll the same again for ya and pass back all the info I get.

[Aric WithanA]

Some good news!

Clean Windows 10 install in a VM, 64 bit using the Wx sample and all worked perfect!  I just did a clean install of python, only the required modules for cefpython and everything worked!!

Now it's off to figure out how to manage the wx window since I can't use CreateWindowEx with the cefwindow.py to render the window to the desktop but that be no your problem, lol!

Looks like problem is solved at least with wx.  

[Aric WithanA]

Well, this is sure interesting and I'm not sure if I'm dumb or not.

Since I access local files the browser settings have to have local enabled so I copied that from my project into the wx when testing.  What I didn't copy was the app settings for CEF when it is initialized.  I had a random thought, maybe if I remove all the app settings from my project and load it with the new cefpython but using the pywin32 and cef window and see what happens.


IT WORKED!

So tested out each of the cef app settings and guess what it was?

appSettings = {"debug": True}

That was what was causing all the delays and lockups.  I remove that and use my same code base with pywin32 and the cefwindow.py and things work and function wonderfully. 

So yea, this whole time it was my fault.  Not sure where that setting came into play, could have been in your example or it came from working with a friend and duplicating code when I first started off trying and learning.  Either way, today has become a freaking wonderful day!!

Thanks again dude for all your hard work.  Now I have to go let the fans know that the app they want will be around here shortly and I've got to get to work getting it done.

-Aric

[Czarek Tomczak]

But that's still strange. Why would debug option set to True cause the issue? Can you check the debug.log file? CEF Python writes to this file using its own logger, however at the same time CEF is also writing to that same file. Maybe there is some conflict, something to do with lock acquired on the file, I don't know. Maybe CEF Python should use CEF log mechanism and that would fix it. It sounds like this is the cause. Here is the code in DebugLog.h:

FILE* pFile = fopen(g_logFile.c_str(), "a");
fprintf(pFile, "[CEF Python] App: %s\n", szString);
fclose(pFile);

It opens and closes the file for each single log write. It might be that CEF that also writes to this file,
opens it during cef initialization, acquires some lock and closes it at shutdown.

[Aric WithanA]

Ah that very well could be what the issue was since this was just a Windows 10 issue since even the legacy cefP worked on Windows 7 with the debug enabled.  Windows 10 might do something different.  

Removing the debug just tells me that a js object event happened:

<cefpython_py27.JavascriptCallback object at 0x000000000398C6C8>

When debug is enabled:

[CEF Python] App: Browser: OnProcessMessageReceived(): V8FunctionHandler::Execute

[CEF Python] V8FunctionHandler_Execute(): functionName=pymanager.getRootPath

[CEF Python] Created javascript callback, callbackId=14, functionName=

[CEF Python] SendProcessMessage(): message=ExecuteJavascriptCallback, arguments size=2

[CEF Python] App: Renderer: OnProcessMessageReceived(): ExecuteJavascriptCallback

No debug and I'm getting a timing change of around 1 up to like 20, which is where you said things should be and everything is working perfectly and moving very smooth.

[Czarek Tomczak]

Hi Aric,

GUI stutterring with debug enabled is now fixed in v56.2 release. Please test.

Best regards.

[Aric WithanA]

Tested out the v57 here today and all worked perfect!  Looks like the issue is taken care of with the debug logging.  cefPython is running smoother than ever and is really making LCARS shine!  Thanks for working through this with me and glad I could help out!

[Czarek Tomczak]

Great to hear that :) Cheers!

[ccesarc...@gmail.com]

Hi, I am facing this same issue using CEF Python 57.0 and Python 3.6.5 64bit in Ubuntu 18.04, a long running function is blocking the UI. I can reproduce the behavior using time.sleep() in any Python function called from JS.

[Czarek Tomczak]

You should create a new topic for your issue. I don't think it is related. time.sleep will block thread and if you run it on UI thread then you will block UI thread.