Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

onEvent does not always update display #191

Closed
joeyh opened this issue May 29, 2017 · 4 comments
Closed

onEvent does not always update display #191

joeyh opened this issue May 29, 2017 · 4 comments

Comments

@joeyh
Copy link

joeyh commented May 29, 2017

A program using onEvent with a timer does not always update the display each time the
timer fires. This example program shows the problem:

import qualified Graphics.UI.Threepenny as UI
import Graphics.UI.Threepenny.Core

main = startGUI defaultConfig $ \window -> do
    foo <- UI.string "foo"
    getBody window #+ [ element foo ]
    timer <- UI.timer # set UI.interval 100
    poschange <- accumE (0 :: Int) $ succ <$ UI.tick timer
    witness <- UI.input
    onEvent poschange $ \x -> do
            element foo # set style
                    [ ("position", "absolute")
                    , ("left", show (x * 5) ++ "px")
                    ]
            -- get UI.checked witness
    UI.start timer

That should, I think, scroll "foo" across the top of the screen. However, it never actually moves.

Uncommenting the commented-out line makes the display update. I don't understand why.

Note that samples/DrumMachine.hs seems to only avoid this problem because it happens to call "get UI.checked box" when playing a sample.

@massudaw
Copy link

It's because threepenny is now batching the calls. Unfortunately it only forces when you call a function. That's why in drumMachine it uses a get UI.checked box.
You can explicitly flush with flushCallBuffer after you set the element foo.
I've made a pull request #192, with a workaround i use to avoid calling it explicitly

@joeyh
Copy link
Author

joeyh commented Jun 20, 2017 via email

@massudaw
Copy link

From what i understand from flushCallBuffer. You want to call it as few times as possible. Currently because all FFI Calls (that return values) need to call it to get the value, we endup flushing in every FFI call.

Ideally all sequential runEval in the server can be batched together.

Simply using onEvent for two events that trigger at the same time would lead to unnecessary flushing pushing twice to the client.

HeinrichApfelmus added a commit that referenced this issue Aug 27, 2017
This mode is like `BufferRun`, but will flush
the buffer at every `onEvent` as well.
This should make the library less confusing
to use in most circumstances.
@HeinrichApfelmus
Copy link
Owner

The new commit above introduces a new default buffering mode, called FlushOften. It ensures that handlers for onEvent also flush the buffer. It is the new default, so the code reported in this issue should work without problems, now.

massudaw pushed a commit to massudaw/threepenny-gui that referenced this issue Aug 28, 2017
This mode is like `BufferRun`, but will flush
the buffer at every `onEvent` as well.
This should make the library less confusing
to use in most circumstances.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants