pmndrs / directed Goto Github PK

Much like issue #15 , the scheduler should have the ability to temporarily disable a tag and all runnables in it.

I run into situations where I want something to run first or last, for example for performance profiling. Now, of course, telling two runnables to be scheduled last runs into a logic problem, only one can truly be last. But would it make sense to have built in tags, first and last where trying to scheduler before first throws an error and trying to scheduler after last throws an error? Then there would be some guarantees that these tags stick your runnables before or after game code.

An example is an init function. A work around is to early out after the first run, but it would be even better if it were just removed from the sort entirely.

I figure the API can look like this, though I don't know the best way it could be implemented.

test('scheduling runnables once', () => {
    const schedule = create();

    add(schedule, aFn, id('A'), once());
    add(schedule, bFn, after('A'), id('B'));
    add(schedule, cFn, after('B'), id('C'));

    run(schedule, {});

    expect(order).toEqual(['A', 'B', 'C']);

    order = [];
    run(schedule, {});

    expect(order).toEqual(['B', 'C']);
})

I have a need to support async runnables, for example a runnable that waits for distributed work on workers to complete before moving on. In this case the runnable would stall the execution of the schedule until it resolves.

This idea came from @pietrovismara. An ID is currently only used for debug, but it also allows an alias for overriding.
This would be useful for mocking during tests, but also for ecosystem integration where you can override a runnable that is loaded by another library.

I have many runnables with the same options:

schedule.add(updateSettings, { tag: PRE_RENDER_GROUP });
schedule.add(updateAttachmentTextures, { tag: PRE_RENDER_GROUP });
schedule.add(updateTransformMatrices, { tag: PRE_RENDER_GROUP });
schedule.add(updateMaterialBindGroups, { tag: PRE_RENDER_GROUP });
schedule.add(generateVertexBuffersLayout, { tag: PRE_RENDER_GROUP });
schedule.add(updateGeometryBuffers, { tag: PRE_RENDER_GROUP });
schedule.add(updateCameraAspectRatio, { tag: PRE_RENDER_GROUP });
schedule.add(updateCameraMatrices, { tag: PRE_RENDER_GROUP });
schedule.add(createPipelines, { tag: PRE_RENDER_GROUP });
...

It would be more convenient and readable to be able to add them all at once:

schedule.add(
  [
    updateSettings,
    updateAttachmentTextures,
    updateTransformMatrices,
    updateMaterialBindGroups,
    generateVertexBuffersLayout,
    updateGeometryBuffers,
    updateCameraAspectRatio,
    updateCameraMatrices,
    createPipelines,
  ],
  { tag: PRE_RENDER_GROUP }
);

I got caught by a bug this evening because while add builds automatically, remove does not and you have to call build yourself for the command to commit. Is this the intended behavior?

Currently, tag/runnable dependencies can only be specified when the tag is created or when the runnable is added to schedule. Add an api to create these relations for a rag or runnable that has already been created/added to the schedule.

Much like add/createTag, the schedule will need to be built after this method is called.

The scheduler should have the ability to temporarily disable a runnable by id or reference. This will cause the scheduler to skip execution of the runnable and should not require a re-build of the schedule.

Using the scheduler with HMR is a bit problematic. So far I have two obvious issues:

1. Duplicates of the same runnable get scheduled if the function regenerates.
2. If it doesn't regenerate it errors out since the same system can't be added twice.

It looks like a solution will involve implementing our own HMR dispose functions: https://vitejs.dev/guide/api-hmr#hot-dispose-cb

This is a fluid list that anyone can edit.

• Documentation #7
• Class sugar layer https://github.com/pmndrs/directed
• React bindings
• Settle on recommended React usage #1
• Settle on expected tag behavior #2 #5

Currently if the same runnable is scheduled twice it throws an error.

add(schedule, aFn, id('A'));
add(schedule, aFn, id('A'));

In imperative apps this probably isn't an issue, you just check to make sure you are scheduling the runnable once, but in dynamic apps like React this can be a real issue. Here are two scenarios where I think it is legitimate to handle this case more gracefully than an error:

1. A user needs to reschedule a runnable. Here it would be ideal to get feedback that it is already scheduled and needs to be removed and readded instead of an error.
2. A schedule call is part of a React component and is called each time a view instance is rendered even though it only needs to mount once.

(2) is relevant since a React component is intended to have all of its behavior and state included with the view. The scheduler, especially with a hook, allows for including global level behavior, usually to do with a simulation.

My proposed solution is to have add return a boolean where true is successfully adding and false is unsuccessful, meaning it was already in the system. Then this can be used as feedback for determining what to do next, either ignore or remove/add to reschedule.

I had been using this example as how to do a quick game loop with the usual stages:

And then to complicate things I add an update camera system that gets the default tag and a new camera tag. I explicitly schedule it before render but the expectation was that I don't have to. Since moveBody is scheduler before render and it also has the default tag I expect the tag to inherit this requirement

Is that correct?

Currently the DAG structure references vertices by an object reference. This is fine, but has a number of awkward side effects, since the object reference is used as a key. This also prevents being able to "override" an item in the graph from an external source (see #6 ).

Replace vertex references with a string or symbol id instead of an object reference.