Asynchronous interface for the client about gfx HOT 5 CLOSED

One way could be to have a separate channel for each type of message. Another is to have multiple 'command builder' things that communicate with the platform thread individually.

from gfx.

Could the enumeration be done by the client rather then the server? The CallNewProgram includes the handle that the program can use to refer to the shader program later.

from gfx.

I might be misunderstanding some part of this, but if you ever need a response from the other side and don't want to move to a promise architecture I think it's actually not such a bad thing to have to wait for the returned value.

You can just move the "waiting" out of each call and handle replies independently:

foo.create_program(...);
foo.create_program(...);
foo.create_mesh(...);
/// blah blah blah
loop {
    match foo.nextReply() {
        ReplyProgram(handle) => // put this handle someplace
        ReplyFooBarBizBaz(handle) => // ditto
        _ => log.error("Unexpected response!")
    }
}

from gfx.

A semi-consensus has been reached to create the handle immediately, load the resource any time later until it's used, and report back a possible error in a designated channel. This is blocked by #22. Please feel free to experiment and propose new ideas (or argument for the existing ones) - nothing is set in stone until a particular PR is accepted.

from gfx.

No longer blocked as of f36d7c9. Implementing the idea will render #9 either irrelevant or impossible.

from gfx.