Is it possible to send from the engine to the javascript code on the webpage?
I need to implement some get methods on the webpage which will gather information from the engine.
You can execute any kind of Javascript on the page, as for composing the string to pass into the execution, that’s something you’d have to do.
However, I will write that up for an improvement! I might be able to get to writing that in the upcoming week.
[QUOTE=KRushin;273568]
Wanted to drop by and say congratulations to the Unreal Grant Well deserved and hope it allows you more time to work on it!
I just woke up to this, and it’s the best news! Thanks to everyone who helped support BLUI. You guys are the reason I was able to keep going.
This will not only help with BLUI, but some upcoming projects as well!
Getting pretty bad performance hits as well on a 4790k and GTX 970. The website http://www.paperjs.org renders fine on Chromium, but the .exe process in UE4 uses one of my cores 100%, and that seems to be where the bottleneck is. Other websites showing off JS canvas things (like Phaser - Examples - Demoscene - Atari Intro) also hit the CPU limit very fast. You’ve set windowless rendering on, but did not touch the framerate setting. Therefore, the framerate of CEF is set to 30FPS. Increasing it does not help at all. I’ve set the framerate to 2FPS, and at each frame of a webpage, the game stutters. This means that the rendering is very, very slow and blocks unreal engine until rendering is done. Windowless rendering does not support GPU acceleration. Turning this off however doesn’t help with the stutter and framerate issues either, though.
I just commented out
parentUI->TextureUpdate(buffer);
And while the process still eats up 100%, there’s no framestutter (although it renders nothing, duh). There is a serious bottleneck in that function.
[QUOTE=Shammah;278568]
Getting pretty bad performance hits as well on a 4790k and GTX 970. The website http://www.paperjs.org renders fine on Chromium, but the .exe process in UE4 uses one of my cores 100%, and that seems to be where the bottleneck is. Other websites showing off JS canvas things (like Phaser) also hit the CPU limit very fast. You’ve set windowless rendering on, but did not touch the framerate setting. Therefore, the framerate of CEF is set to 30FPS. Increasing it does not help at all. I’ve set the framerate to 2FPS, and at each frame of a webpage, the game stutters. This means that the rendering is very, very slow and blocks unreal engine until rendering is done. Windowless rendering does not support GPU acceleration. Turning this off however doesn’t help with the stutter and framerate issues either, though.
I just commented out
parentUI->TextureUpdate(buffer);
And while the process still eats up 100%, there’s no framestutter (although it renders nothing, duh). There is a serious bottleneck in that function.
This is going to be looked into, thanks for the feedback. I will look into possibly running the texture render in another thread as well as looking at the texture update method
I just pinpointed the resource hog closer. It appears that the bottleneck comes from the code you blatantly copied from the VQueloUIPlugin over at https://github.com//VaQuoleUI/blob/master/Source/VaQuoleUIPlugin/Private/VaQuoleUIComponent.cpp.
I commented out the rendering part, and the framerates more than halves and the stutter is immense. The little @TODO mentions it’s not a big deal. Apparantly the copying butchers my framerate on a pretty beastly PC.
// @TODO This is a bit heavy to keep reallocating/deallocating, but not a big deal. Maybe we can ping pong between buffers instead.
TArray<uint32> ViewBuffer;
ViewBuffer.Init(Width * Height);
FMemory::Memcpy(ViewBuffer.GetData(), buffer, size);
TextureDataPtr dataPtr = MakeShareable(new TextureData);
dataPtr->SetRawData(Width, Height, sizeof(uint32), ViewBuffer);
// Clean up from the per-render
ViewBuffer.Empty();
buffer = 0;
[QUOTE=Shammah;278601]
I just pinpointed the resource hog closer. It appears that the bottleneck comes from the code you blatantly copied from the VQueloUIPlugin over at https://github.com//VaQuoleUI/blob/master/Source/VaQuoleUIPlugin/Private/VaQuoleUIComponent.cpp.
I commented out the rendering part, and the framerates more than halves and the stutter is immense. The little @TODO mentions it’s not a big deal. Apparantly the copying butchers my framerate on a pretty beastly PC.
// @TODO This is a bit heavy to keep reallocating/deallocating, but not a big deal. Maybe we can ping pong between buffers instead.
TArray<uint32> ViewBuffer;
ViewBuffer.Init(Width * Height);
FMemory::Memcpy(ViewBuffer.GetData(), buffer, size);
TextureDataPtr dataPtr = MakeShareable(new TextureData);
dataPtr->SetRawData(Width, Height, sizeof(uint32), ViewBuffer);
// Clean up from the per-render
ViewBuffer.Empty();
buffer = 0;
Understand that code was from VaQueloUI, which is also under the MIT license, and I have included said license here:
The master branch just got updated with a small performance fix. I was able to remove unnecessary memcopy operations. Only one memcopy remains, from the CEF buffer to the texture itself. I’m not sure if I can remove that as well; setting the texture data pointer directly to the given CEF buffer pointer does not seem to work. It’s the only remaining bottleneck concerning texture updates. At 1920x1020, this is about 74MB per memcopy. Calling that each 30FPS is still a big strain I think.
[QUOTE=Shammah;278672]
The master branch just got updated with a small performance fix. I was able to remove unnecessary memcopy operations. Only one memcopy remains, from the CEF buffer to the texture itself. I’m not sure if I can remove that as well; setting the texture data pointer directly to the given CEF buffer pointer does not seem to work. It’s the only remaining bottleneck concerning texture updates. At 1920x1020, this is about 74MB per memcopy. Calling that each 30FPS is still a big strain I think.
I remember trying to do that (using the pointer directly to the CEF buffer) quite a while ago when things first started and discovering it didn’t work for some reason. I’m interested in figuring out that hurtle as well.
[QUOTE]
With off-screen rendering CEF does not create a native browser window. Instead, CEF provides the host application with invalidated regions and a pixel buffer and the host application notifies CEF of mouse, keyboard and focus events. Off-screen rendering does not currently support accelerated compositing so performance may suffer as compared to a windowed browser.
Well deserved and hope it allows you more time to work on it!
