Taskflow update #1

All about UI

 To be able to properly show my taskflow prototype to the public i need to concentrate on UI, even though i consider this UI just a stand-in for a proper web-ui. Doesn't matter how good your system is if user cannot interact with it in a friendly way...

 Одним из главных компонент для первой публичной демки таскфлоу, как ни странно, является интерфейс пользователя. Несмотря на то, что я всё ещё рассматриваю этот конкретный интерфейс скорее как заглушку, всё же как бы хорошо не работал сервер, если юзер не может с ним взаимодействовать, то какой в нём смысл...

 

So this update is mainly about the UI. Sure there is a bunch of node libraries out there (to name a few: nodz, nodeeditor, nodegraph-pyqt) so why not use one of them? Well, since i need my nodes to do some unique things and natively interact with task representations, and since ui here is just a client and server has to confirm and perform every actual action (like node creation/destruction/connection) - I just decided that modifying existing lib will take as much time as writing my own, but not from scratch - Qt's scene framework is an excellent base.

Так что данный апдейт - в основном касается интерфейса. Существует куча библиотек для создания своих нодовых графов (например nodz, nodeeditor, nodegraph-pyqt), но взяв во внимание то, что я хочу заложить в свои ноды некоторые уникальные фичи, и иметь плотное и нативное их взаимодействие с визуальным представление тасков. Плюс этот нодовый интерфейс является клиентом, и каждое действие над нодами (создание/удаление/соединение) должен утверждать сервер. Так что я решил, что дорабатывание существующих библиотек займет минимум столько же времени, сколько создание нодового фреймворка с нуля. Да и что там, не с нуля - QTшный scene фреймворк является отличной базой.

At this point i've reached the bare minimum of features: you can create nodes, delete nodes and connect them. well, i've definitely forgot renaming nodes, and that is pretty important feature, unless you are fine with all the nodes having same currently default name "bark woof"...

На данный момент, пожалуй, реализован абсолютный минимум фич, позволяющих работать с графом: ноды можно создавать, удалять и соединять. Забыл сделать переименование... Пожалуй, это довольно важная фича, если вы хотите назвать ноды как-то более осмысленно, чем дефолтное на данный момент имя "bark woof"...

And since we are talking about UI nodes, why not talk a bit in more details how the nodes are supposed to work. I've already described the main idea in previous post, and here I'll add a bit about inputs and outputs.

Ну и раз уж мы говорим о нодовом интерфейсе, давайте слегка коснемся нодовой логики. Основную идею нод и как они процессят таски я рассказал в прошлом посте, тут ничего не изменилось, так что сейчас лишь немного дополню то объяснение входами и выходами нод.

Every node type defines it's inputs and outputs. All tasks coming from any input will be processed the same way by scheduler, the only difference is that each task will be marked with the input it came in with, so the node's implementation can actually process tasks in different way depending on input mark.

Каждая нода определяет свои входы и выходы. Все таски, приходящие в ноду по любому из инпутов, сваливаются в одну кучу и обрабатываются шедулером одинакого, за исключением того, что каждый таск получает пометку, по какому инпуту он пришёл в ноду, и собственно код ноды может решить обрабатывать таски с разными метками входа по-разному.

As for outputs - node type implementation decides which output to send the task to. It can be a static decision, like in most cases, for example, when task produces children tasks - you will probably want to send children tasks to a separate output from where the parent task was going. Like in case of ifd generator - incoming task with hip file name and driver path is processed, newly spawned tasks for mantra are sent through second output, while finished original incoming task will be send further through the first output, and can be processed further.
But it can as well be a dynamic decision by node based on task attributes, or even payload invocation results. A simple split node based on attribute value may be ab example here.

Насчет выходов - нода сама решает, куда отправить обработанные ей таски. Это решение может быть статическим - например если таск пораждает дочерние таски - скорее всего нода бы хотела отправлять эти таски по другому выходу, нежели исходный таск. На примере ifd генератора - исходный таск имеет путь до сцены и мантры в ней. в процессе исполнения нагрузки рабочим новые таски, имеющие в аттрибутах путь до ifd файла, который нужно отрендерить, будут отправлены по второму выходу, тогда как собственно входной таск будет отправлен по первому, и может быть дальнейше обработан, например он может приходить в композ ноду и инициировать композитинг отрендеренных ранее кадров.
Но решение, куда отправить таск, может быть и динамическим. Нода может проанализировать аттрибуты таска, или даже результат выполнения нагрузки рабочим и решить, куда отправлять каждый конкретный таск. Например, это может быть простая нода, разделяющая таски на два или более потоков на основе порога какого-либо аттрибута. 

Next time i'll explain synchronization concepts in taskflow, and we'll see a more complicated rendering setup example

В следующий раз я объясню концепции синхронизации тасков в таскфлоу, и мы посмотрим на более сложные сетапы рендера