Disclosure Statement: This site contains affiliate links, which means that I may receive a commission if you make a purchase using these links. As an eBay Partner, I earn from qualifying purchases.

Network huge delay.

Post Reply
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

Hi,

Where is the cache and cookies directory ?
Try using a local directory for the cache or "in-memory" cache.

Perhaps your antivirus, firewall or some Windows features like UAC are slowing down your application. Try adding it to the white list.
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

I forgot to add that perhaps you need to set GlobalCEFApp.SetCurrentDir to TRUE if you run it from a network drive or a desktop shortcut.
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

Another known reason for slow startup is setting TChromium.ProxyType to CEF_PROXYTYPE_AUTODETECT
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

To load the first page as soon as the browser is initialized set the TChromium.DefaultURL property before the TChromium.CreateBrowser call.

The SimpleBrowser2 demo sets the TChromium.DefaultURL property in the TForm.OnCreate event :
https://github.com/salvadordf/CEF4Delph ... 2.pas#L144

And it calls TChromium.CreateBrowser in the TForm.OnShow event :
https://github.com/salvadordf/CEF4Delph ... 2.pas#L155

Alternatively, you can wait for the browser to be initialized to load the first URL. Some other demos use the TChromium.OnAfterCreated event to send a CEF_AFTERCREATED message to the main form. Those demos enable the interface and load the first URL when the form receives the CEF_AFTERCREATED message.

Perhaps the delay introduced by the network is affecting the browser initialization sequence.

As you can see in the SimpleBrowser2's code comments, TChromium.CreateBrowser needs to be called after GlobalCEFApp.GlobalContextInitialized is set to TRUE.

GlobalCEFApp.GlobalContextInitialized is updated in a CEF thread while the TChromium.CreateBrowser call is done in the main thread.

The demos solve this problem with a simple TTimer that tries to call TChromium.CreateBrowser several times until it succeeds but it might be necessary to use a synchronization object to do this correctly in a network environment.

Please, build the SimpleBrowser2 demo and test it in your network to see if it has the same problems.

It would be helpful to test the official CEF sample application too :
http://opensource.spotify.com/cefbuilds ... nt.tar.bz2
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

penny19 wrote: Mon Jun 03, 2019 12:59 pm In order to be more specific as I explained to you before we have an exe from which several bpls are being loaded dynamically.
In this exe there is a pagecontrol and when we open an "item" (let's say an invoice, an order etc) there is being created dynamically a new tab.
For that reason in development we use frames instead of forms.
Is this something that may bother CEF4Delphi?
BriskBard uses CEF4Delphi and it creates almost everything dynamically. That shouldn't be a problem.
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

I'm sorry I should've given a more detailed explanation about the CEF initialization.

If you create multiple browsers when your app starts then perhaps you should try an alternative way to do that.

GlobalCEFApp.GlobalContextInitialized is set to true only once in the GlobalCEFApp.OnContextInitialized event when the application starts.

If you wait for GlobalCEFApp.GlobalContextInitialized to be true before creating any browser then you can delete the timers because TChromium.CreateBrowser will work correctly the first time it's called.

The MDIBrowser and ToolBoxBrowser demos use the GlobalCEFApp.OnContextInitialized event to send a CEFBROWSER_INITIALIZED message to the main form to enable the interface :
https://github.com/salvadordf/CEF4Delph ... m.pas#L105

They also use the TForm.OnShow to enable the interface if GlobalCEFApp.GlobalContextInitialized is true :
https://github.com/salvadordf/CEF4Delph ... m.pas#L244
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: Network huge delay.

Post by salvadordf »

Sorry for the long delay. :oops:

I could make some tests running a modified MDIBrowser demo from a network folder and the final performance was fine.

I inserted a USB pendrive into my router and enabled the samba service. The pendrive had a copy of the MDIBrowser.exe file with this code in the DPR file :

Code: Select all

program MDIBrowser;

{$I cef.inc}

uses
  {$IFDEF DELPHI16_UP}
  Vcl.Forms,
  WinApi.Windows,
  {$ELSE}
  Forms,
  Windows,
  {$ENDIF }
  uCEFApplication,
  uMainForm in 'uMainForm.pas' {MainForm},
  uChildForm in 'uChildForm.pas' {ChildForm};

{$R *.RES}

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

begin
  CreateGlobalCEFApp;

  GlobalCEFApp.FrameworkDirPath     := 'c:\binaries';
  GlobalCEFApp.ResourcesDirPath     := 'c:\binaries';
  GlobalCEFApp.LocalesDirPath       := 'c:\binaries\locales';
  GlobalCEFApp.cache                := 'c:\binaries\cache';
  GlobalCEFApp.UserDataPath         := 'c:\binaries\User Data';
  GlobalCEFApp.SetCurrentDir        := True;

  if GlobalCEFApp.StartMainProcess then
    begin
      Application.Initialize;
      Application.CreateForm(TMainForm, MainForm);
      Application.Run;
    end;

  DestroyGlobalCEFApp;
end.
As you can see, it uses a local copy of the CEF binaries and a local cache directory too. The rest of the code in MDIBrowser was not modified.

With this configuration the only file transmitted through the network is MDIBrowser.exe and once it's running it only uses local libraries and cache files.

My local network has some bottlenecks with the old USB pendrive speed, the samba server in the router and the virtual machine I used to do the tests. These conditions were far from perfect but MDIBrowser was loaded in a few seconds and I could open several web pages without delays.

I downloaded the project in your dropbox folder and tested it. My suggestions are these :
  • Set GlobalCEFApp.UserDataPath to a local directory in the DPR file.
  • All the tabs need to be closed properly or you will see crashes when you try to close the app. Applications with multiple browsers require more steps to close the app safely. Read the code comments in the SimpleBrowser2 demo about the "Destruction steps". Then read the code comments in all the PAS files from the MDIBrowser and TabBrowser demos before creating your own tab destruction in your app.
  • Remember that each local "cache" directory can only be used by one app. If you try to run several copies of the same app and all of them try to use the same cache you will have problems. However, there's no problem if you create multiple browsers using the same cache directory if all the browsers are created internally by the same app.
  • frmMainForm needs a procedure to receive the CEFBROWSER_INITIALIZED message. In that procedure you can enable the user interface.
  • All applications with CEF browsers need to handle the WM_MOVE, WM_MOVING, WM_ENTERMENULOOP and WM_EXITMENULOOP messages. Copy the code that handle those messages in the TabBrowser demo to your application.
Post Reply