Welcome @al3x!

and @paulb

When queueing things in an inactive tab with re-frame’s dispatch I need to first focus the window or at least make parts of it visible again before the handler fires — is there a way to mitigate this?

I tried dispatch-sync without much of a difference

@martinklepsch: re-frame’s core async queue of events is stopped or reagent’s rendering? I would guess the later

it uses requestAnimationFrame which gets paused in inactive tabs in some browsers

It’s definitely also re-frame’s queue. Rendering too I believe but that’s not bothering me for now.

AFAIK re-frame uses setTimeout, which could slow-down your event queue if tab is inactive, but not stop it

https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljs#L43

This is in an electron app fwiw. Sending a notification using a re-frame handler on a fs.watch event. When I add the plain (js/Notification. …) call to the watch callback it immediately triggers a notification

setTimeout/setInterval could be throttled to 1 event per second if tab is inactive, according to this: http://stackoverflow.com/questions/15871942/how-do-browsers-pause-change-javascript-when-tab-or-window-is-not-active

so if you expect fs.watch to post many events… this is not the way to go, I guess

it’s a low-frequency event. The handler is immediately ran if the window is even only partially visible. OS X Expose or moving a window that’s covering out of the way is enough

ok, then it is maybe an electron optimization thing

I recall a discussion, someone wanted to improve re-frame’s queue throughput by using https://code.google.com/p/closure-library/source/browse/closure/goog/async/nexttick.js

instead of setTimeout 0

anyways, you can start by commenting out that setTimeout in re-frame’s code

@darwin: http://dev.clojure.org/jira/browse/ASYNC-137

maybe it is problem of core.async itself, internally it might do setTimeout too, I’m not familiar with its internals

@mikethompson: ah, thanks ^

@martinklepsch: just to state the obvious, the "problem" with background tabs is that they are throttled. For example, the "annimationFrames" are not happening every 16ms. You might be lucky to have one per second, probably less. In its main event loop, re-frame goes to some trouble to "hand back control" to the browser, to make sure it doesn't "Hog the CPU" .... the trouble with that approach is that it can take a long time to get an event handled when the app is in a throttled background tab

re-frame is nicely handing back control the browser, and then the browser, because of throttling, in not then giving it back for a veeeeeeeery long time.

So the handling of the (dispatch [xxx]) takes a while.

@mikethompson: is there some maximum you’d say it takes?

@martinklepsch: I've never measured it

I read the CPU Hogging wiki page and I think here it takes longer than what could be considered normal. (waiting for it since I started typing this ~20s)

And now I got it.

@martinklepsch: but dispatch-sync has no queue, it just happens

By that, I mean the handler just runs.

Any screen updates that arise from the event handler running will be handled by an anninmationFrame.

And, if things are throttled, that could take a while.

Question: is the problem the "handling of the event" or is the problem the speed with which the window subsequently updates. I'm getting the impression that your event handler is calling a fucntion in the electron API. What does that function do?

Sorry, I've read back. I can now see what you said before. You have an fs.watch which dispatchs an event ... and you want the event handler to use the js/Notification API.

The basic thing I’m doing is this: 1. watch filesystem for some changes, pipe them into the system using dispatch 2. under some specific conditions call (js/Notification. “Test”) to trigger desktop notifications

How long does it take for the fs.watch callback to run, I wonder. To kick start the process.

@mikethompson: I added the js/Notifcation. call directly to the callback that later calls dispatch and the notification fires immediately

You've got multiple steps there ... and in a throttled tab each of them could take seconds

Hmm.

If you use dispatch-sync (from your fs.watch callback) then you should likewise see something instant

(Assuming the event handler servicing the dispatch-sync does the js/Notification call)

Right, that works. Then I only have to decouple that notification logic from the rest that can happen once the app has been activated again.

@mikethompson: Thanks

@martinklepsch: no problems. Glad it works