aRestless

SharedWorker not working in Overwolf?

Recommended Posts

I wanted to bump this up again.

 

SharedWorkers would be incredibly useful, because in contrast to dedicated workers they can be accessed from other workers and from other windows. That means: Not only could we have a reliable, consistent, message driven alternative to abusing localStorage, but this would also take load from the main thread.

 

For example: In my app the main thread is busy rendering stuff most of the time (placing, resizing, moving divs and their content). But there are also tasks that can run in parallel. For these steps I have a kind of a pipeline architecture, that passes information from one worker to the other. So if you have workers A and B, and A has finished its work and wants to pass the result to B, with only dedicated workers available, the result can't be sent directly. You have to wait for the main thread to have time, which then does nothing but taking the message from A and sending it to B. So there is an unnecessary waiting time if the main thread is currently busy and if you aren't careful with your "scheduling", queues of finished results from worker A can grow indefinitely.

 

So, in short: SharedWorkers would solve some issues when it comes to heavy load and clean design in more complex applications. Chrome supports them, please support them, too.

Share this post


Link to post
Share on other sites

I wanted to bump this up again.

 

SharedWorkers would be incredibly useful, because in contrast to dedicated workers they can be accessed from other workers and from other windows. That means: Not only could we have a reliable, consistent, message driven alternative to abusing localStorage, but this would also take load from the main thread.

 

For example: In my app the main thread is busy rendering stuff most of the time (placing, resizing, moving divs and their content). But there are also tasks that can run in parallel. For these steps I have a kind of a pipeline architecture, that passes information from one worker to the other. So if you have workers A and B, and A has finished its work and wants to pass the result to B, with only dedicated workers available, the result can't be sent directly. You have to wait for the main thread to have time, which then does nothing but taking the message from A and sending it to B. So there is an unnecessary waiting time if the main thread is currently busy and if you aren't careful with your "scheduling", queues of finished results from worker A can grow indefinitely.

 

So, in short: SharedWorkers would solve some issues when it comes to heavy load and clean design in more complex applications. Chrome supports them, please support them, too.

You could use window.postMessage() API to communicate between windows

 

Also I think you could use a worker, which could use post messages to communicate with other windows using window.postMessage to achieve kinda what you re after and workers can spawn other workers.

Share this post


Link to post
Share on other sites

Thanks for your suggestions BobDev.

 

My workaround will probably be using a dedicated window for the parallel computation stuff and one only for rendering. Unfortunately, window can't be accessed from a worker, so you can't send messages to a window from a worker directly. I'm not even sure if window.postMessage works in Overwolf at all, because as far as I understand, in Overwolf there is no way to get a reference to another window object, as opening other windows in an Overwolf application only works through the identifier based API call.

Share this post


Link to post
Share on other sites

Thanks for your suggestions BobDev.

 

My workaround will probably be using a dedicated window for the parallel computation stuff and one only for rendering. Unfortunately, window can't be accessed from a worker, so you can't send messages to a window from a worker directly. I'm not even sure if window.postMessage works in Overwolf at all, because as far as I understand, in Overwolf there is no way to get a reference to another window object, as opening other windows in an Overwolf application only works through the identifier based API call.

Yes, worker cant access window.

But postMessage should work, each window has this signature, that you can pass to overwolf browser and it would open your app window:

     overwolf-extension://<OVERWOLF APP UID HERE>/Files/index.html

so in theory you could talk between windows this way, but it need to be tested

Share this post


Link to post
Share on other sites

Yes, worker cant access window.

But postMessage should work, each window has this signature, that you can pass to overwolf browser and it would open your app window:

     overwolf-extension://<OVERWOLF APP UID HERE>/Files/index.html

so in theory you could talk between windows this way, but it need to be tested

It almost worked, unfortunately overwolf window object does not have postMessage function, so it is again something that Overwolf team could implement.

 

If you even obtain the window with overwolf.windows.obtainDeclaredWindow you cant comunicate with it because postMessage is not in that object

Share this post


Link to post
Share on other sites

Quick update: just tested it with a super alpha version of the next Overwolf release (note that 84 just went live) and the code you posted works and pops the prompt.

If all further tests go smooth, this should be out in about a month.

Also, we're looking into adding custom user agents for the version after the next one. This is some time from now, so it's just a heads up.

Share this post


Link to post
Share on other sites

Wow that's great news! I'll account for that in my architecture. That could step up performance (and clean designs) quite a bit.

 

Do you know if it works across browser windows? If you haven't confirmed that yet, I could try to put together a minimal example.

Share this post


Link to post
Share on other sites

Does this mean I will be able to send messages between windows using postMessage?

 

Back when we talk about those features I was trying to obtain window and call postMessage on it, so it would look something like this:

overwolf.windows.obtainDeclaredWindow("SubWindow", function(result){
        if (result.status == "success"){
              var origin = window.location.href;
              result.postMessage("test", origin)
        }
    });
Basically I was trying to achive the same as in this example:
/*
 * In window A's scripts, with A being on <http://example.com:8080>:
 */

var popup = window.open(...popup details...);

// When the popup has fully loaded, if not blocked by a popup blocker:

// This does nothing, assuming the window hasn't changed its location.
popup.postMessage("The user is 'bob' and the password is 'secret'",
                  "https://secure.example.net");

// This will successfully queue a message to be sent to the popup, assuming
// the window hasn't changed its location.
popup.postMessage("hello there!", "http://example.org");

function receiveMessage(event)
{
  // Do we trust the sender of this message?  (might be
  // different from what we originally opened, for example).
  if (event.origin !== "http://example.org")
    return;

  // event.source is popup
  // event.data is "hi there yourself!  the secret response is: rheeeeet!"
}
window.addEventListener("message", receiveMessage, false);
/*
 * In the popup's scripts, running on <http://example.org>:
 */

// Called sometime after postMessage is called
function receiveMessage(event)
{
  // Do we trust the sender of this message?
  if (event.origin !== "http://example.com:8080")
    return;

  // event.source is window.opener
  // event.data is "hello there!"

  // Assuming you've verified the origin of the received message (which
  // you must do in any case), a convenient idiom for replying to a
  // message is to call postMessage on event.source and provide
  // event.origin as the targetOrigin.
  event.source.postMessage("hi there yourself!  the secret response " +
                           "is: rheeeeet!",
                           event.origin);
}

window.addEventListener("message", receiveMessage, false);
Is this now possible or overwolf window still does not have such method?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now