MrShoor
у тебя там не только рендер но и редактирование на лету еще, не дави так сильно!
Aroch
> у тебя там не только рендер но и редактирование на лету еще, не дави так
> сильно!
Редактирование кстати подтормаживает, это видно, когда в конце происходит пуш группы треков. Но там реально сложные алгоритмы начинают работать. А вот собственно обновление рендера занимает меньше миллисекунды.
MrShoor
> это видно, когда в конце происходит пуш группы треков.
в идеале вынести в отдельный поток или считать обновление не за один кадр, тогда не сильно важно будет если оно визуально будет запаздывать, но при этом ввод пользователя останется плавным.
Aroch
> в идеале вынести в отдельный поток или считать обновление не за один кадр
Там особо не наигрешь. Там сами алгоритмы съедают 95% времени. Если бы им мешало что-то из основного потока, скажем рассчет пушинга 50% и все остальное 50% - то имело бы смысл.
MrShoor
> Там особо не наигрешь. Там сами алгоритмы съедают 95% времени.
я не про это, у тебя сейчас видно что линию которую ведешь за курсором в момент пушинга она тоже тормозит. Смысл есть разделить рассчеты для того чтобы обновлять пушинг пускай раз в 5 кадров и с запозданием, но ввод и рендер останется плавным.
Aroch
> Смысл есть разделить рассчеты для того чтобы обновлять пушинг пускай раз в 5
> кадров и с запозданием, но ввод и рендер останется плавным.
А, понял. Да, наверное тут можно было бы что-то придумать.
MrShoor
и несколько вопросов:
1) есть ли множественное выделение и редактирование сегментов? (выделить два три в разных местах и начать двигать)
2) перед тем как делать пушинг делаешь ли примитивную оптимизацию выбирая только те сегменты что попали в зону редактирования?
Aroch
> 1) есть ли множественное выделение и редактирование сегментов? (выделить два
> три в разных местах и начать двигать)
Да, есть.
> 2) перед тем как делать пушинг делаешь ли примитивную оптимизацию выбирая
> только те сегменты что попали в зону редактирования?
Там все не так просто. Там множество параметров и опций роутинга (роутинг - собственно процесс прокладки дорожек). Так же еще множество правил в целом, которые нельзя нарушать. Поэтому роутингом у нас занимается целая команда разработчиков. Я там ничего не делаю. А занимаюсь я сугубо рендером. То есть моя задача - быстро показать что они там нароутили.
MrShoor
> Я там ничего не делаю. А занимаюсь я сугубо рендером. То есть моя задача -
> быстро показать что они там нароутили.
тогда те тормоза сугубо их зона ответственности.
> Да, есть.
подозреваю что они весь слой (всю схему) каждый раз пытаются проверить. Я бы сделал так. На onBeginEvent(drag/draw new/etc) - создаем две копии редактируемого слоя (думаю что одна копия уже итак делается). onMoveEvent - обновляем в фоне, по завершении обновления делаем swap указателей на актуальные данные для рендера и продолжаем обновлять. onDoneEvent - завершаем обновление в фоне, заливаем данные. При отмене действия берем оригинальные данные которые всё это время были без изменений.
Aroch
> подозреваю что они весь слой (всю схему) каждый раз пытаются проверить.
Да не, там достаточно много умных оптимизаций, поверь. Такого наивного кода там нет.
MrShoor
> Да не, там достаточно много умных оптимизаций, поверь. Такого наивного кода там
> нет.
когда оптимизировать нечего, остается только выносить вычисления в фон, влиять на ui не дело в этот момент.
Aroch
> очередное блаблабла, даже я не работая ни разу с юнити нашел опровержению твоим
> словам.
И нам конечно же его не покажешь?
Aroch
> И пользователи плагина это не пользователи игры, а такие же
> разработчики и они могут позволить себе обновить среду разработки до
> актуальной.
Твоя аргументация говно и вот почему.
Могут позволить. Только обычно этого не делают из-за проблем совместимости, новых багов и принипа "работает не трогай".
Когда найдёшь актуальный процент пользователей на каждую версию, тогда и можешь рассказывать влажные истории.
Пока что единственная и доступная информация от которой можно отталкиваться - это статистика обновлений пару лет назад от самих юнитеков.
Спустя месяц релиза обновилось всего 7% разрабов. Пол года все сидят на предыдущей версии.
На отсталых версиях сидят около 40%.
2019 версия вышла около полу года назад, экстраполируя можно сказать что около 50% людей сидят на других версиях.
Kripto289
> И нам конечно же его не покажешь?
уже показал, читай внимательней.
> Только обычно этого не делают из-за проблем совместимости, новых багов и
> принипа "работает не трогай".
спасибо, твое безусловно "авторитетное" мнение было учтено /_-
> экстраполируя можно сказать что около 50% людей сидят на других версиях.
и большая часть из них или забила или используют юнити побаловаться, смотри на процент среди выпущенных игр и какую версию юнити они использовали, а не на каждого Васю который хоть раз попользовался юнити.
Aroch
ничего ты не показал. Высосал из пальца фантизию, облажался, и теперь будешь 10 страниц доказывать в стиле "я прав, не веришь? - спроси у меня".
Когда тебя ткнули лицом в том, что ты выдумываешь то, чего нет, ты вместо того что бы покаятся несешь новую высосанную из пальца дичь типа этой:
Kripto289
я тебе в личке написал где есть актуальная инфа по версиям
вот например на июнь
но для мамкиных борщехлёбов потеря двух третей пользователей - не проблема.
MrShoor
ну ты молодец, я ж тебе сказал, что ты еще хочешь услышать?
вопрос не в том работает/не работает, а в том как работает и с какой скоростью. У меня тоже работает, и очень быстро, но я просто закладываю в архитектуру запас по производительности, потому что если у тебя просто линии в 2д рисуются на рабочих станциях, то у меня линии+много всего другого нужно рисовать, и не на рабочих станциях, а на чем угодно.
Тема в архиве.