По 2-му примеру: зачем указывать scheduler в make_count? Там создаётся фабрика sender-а, который формирует задачу по подсчёту слов в файле. Зачем ему знать о том, что его будут запускать в thread пуле? По-моему, это неправильное разделение ответственности, и конкретный scheduler нужно указать позже. И, кстати, непонятно, зачем вообще использовать senders/receivers в первой части, где подсчитываются слова. Подсчёт слов можно написать и обычным способом, и это будет гораздо более читаемо. Что хотелось бы сделать, так это взять функцию типа "count_words(string path)", сделать из неё 3 сендера в трёх строчках кода, сделать scheduler с thread пулом, и потом вызвать when_all, чтобы выполнить эти функции параллельно, внутри какого-то более сложного графа исполнения. Тогда целесообразность сендеров/ресиверов была бы более очевидной.
completion_signatures_of_t содержит сигнатуры set_value, set_stopped и set_error, которые в пользовательском коде нигде не используются. Зачем пользователю информация об этих сигнатурах? Её смысл не очевиден, и, по-моему, она выглядит как пример плохой архитектуры стандартной библиотеки, потому что требует знания внутренностей реализации, которые не используются пользователем напрямую.
Автор, Вы не могли бы посоветовать мемуары советских инженеров из разных десятилетий XX века? По которым можно увидеть, как работали советские предприятия и НИИ, и как всё это менялось со временем?
Идея звучит прекрасно, но реализация откровенно плохая. У меня, как и у многих комментаторов, выводится только предложение пересоздать профиль и потратить ещё несколько часов на анкету, чего я, естественно, делать не буду. И судя по ответам автора, они даже не собираются решать эту проблему. Им кажется, что всё так и должно работать.
Арендодателем может выступать фирма, владеющая производственными возможностями, которая может проапгрейдить ноутбук так, что с точки зрения потребителя он будет совершенно новый. Отлить новый корпус, поставить более мощную электронику, а старую использовать в других продуктах, либо продать тем, кто сможет её использовать в других продуктах. Это однозначно выгоднее существующей бизнес-модели, когда всё изделие выкидывается вместе с деталями, пригодными для использования. Вообще, конечным арендодателем может выступать условный асус.
> Арендованная - стираем в тазике пока не приедет тот-самый-специалист.
Если вас не устраивает, что специалист не приходит в течение часа, обратитесь к другой фирме. Бизнес, который не может предоставить хороший сервис, не выживает на рынке.
Есть такое явление, как копроэкономика, когда производитель сознательно снижает надёжность изделий, чтобы повысить прибыть от продажи запчастей или новых изделий. И вот меня давно мучает вопрос, почему до сих пор не появилась модель бизнеса, которая решает эту проблему, и я давно хотел задать его кому-то, связанному с ремонтом техники.
Допустим, есть некая фирма, которая предоставляет домохозяйству свою бытовую технику и электронику за ежемесячную плату (примерно так, как большинство интернет-провайдеров предоставляют роутер). Если, к примеру, ноутбук выходит из строя, то фирма за свой счёт его чинит, либо заменяет на новый, а старый разбирает на запчасти. Такая фирма будет покупать только надёжную технику, поскольку у неё достаточный уровень экспертизы, чтобы найти такую технику. Производители получат стимул делать надёжную технику, чтобы удовлетворить спрос со стороны таких фирм.
Кто-нибудь может рассказать, почему такая бизнес-модель не прижилась на рынке?
Какие все? В Азербайджане одна ТЭЦ есть только в Баку, насколько я знаю, и к ней подключён не весь город. В Грузии и в Армении центрального отопления вообще нет.
Справились бы и без Йоты. Отрубили бы электричество, Интернет, заглушили бы вайфай и сотовую связь. А скорее всего, просто приняли бы на входе или выходе из квартиры, и сразу забрали бы телефон.
Благодарю за то, что указали на отсутствие гамма-коррекции. Я полез разбираться с этой темой и многое для себя уяснил. У меня и правда отсутствовала гамма-коррекция, и это, наверное, было заметно по плохому антиалиасингу. Вычисления с цветом происходили в линейном пространстве, потом к ним применялась LUT монитора, к этому добавлялась низкая точность хранения тёмных тонов в 8-битном буфере, и получались рваные края примитивов. Теперь цвета преобразуются в линейное пространство перед отправкой в OpenGL, а при выводе на экран — в sRGB (аппаратно). Выглядит получше.
Непонятно, почему в Qt по умолчанию происходит вывод в рендербуфер с линейным цветовым пространством, и для поддержки sRGB приходится настраивать QOpenGLWidget.
В своём рабочем проекте я это тоже исправил (приятно открывать для себя мир; у нас ни одного синьора в команде, вот и приходится наступать на грабли:)). Там тоже улучшился антиалиасинг и фильтрация текстур. Ещё раз спасибо!
Если всё ещё интересно, как выглядит аддитивный блендинг с нормальной гамма-коррекцией, то вот, что у меня получилось:
Внизу слева обычный аддитивный блендинг (Вы правы, в белый мы теперь вываливаемся медленнее), справа — с экспозицией 1.0 - exp(-0.8*c).
Теперь пара слов для тех, кто ещё считает, что WBOIT — это аналог аддитивного блендинга, с той же областью применения. Вот на этой картинке сверху видно, что тёмные цвета (у длинных радиальных треугольников с жёлтыми кромками) при аддитивном блендинге практически не влияют на результирующий цвет (именно потому что они тёмные, т.е. имеют маленькие числовые значения). При использовании WBOIT их вклад в результирующий цвет пропорционален значению opacity, они реально могут затемнить свой кусок экрана. Мы вычисляем взвешенную сумму цветов, значит, результат никогда не выйдет за пределы цветов, которые мы смешиваем. Это позволяет использовать метод для рендеринга прозрачных объектов. Аддитивный блендинг (хоть с экспозицией, хоть без) подходит для рендеринга источников света. Результат может выйти за пределы смешиваемых цветов, как в тёмную, так и в светлую сторону.
У меня вышло, что аддитивный блендинг с экспозицией по сравнению с WBOIT — это минус 2 текстуры, минус 1 фреймбуфер, и шейдер конечного постпроцессинга чуть попроще. Положа руку на сердце, это не сильно упрощает рендеринг. К тому же, коэффициент экспозиции надо подбирать для каждой конкретной сцены.
Если я правильно понял, то это и есть то, что я нарисовал в предыдущем комментарии. Без деления на получается взвешенная сумма цветов вместо взвешенного среднего. Т.е. мы умножаем цвет каждого фрагмента на его альфу, складываем всё это и выводим на экран. Сложная конструкция из фреймбуферов нужна как раз для того, чтобы, во-первых, поделить на , во-вторых, особым образом смешать цвета прозрачных и непрозрачных объектов, раз уж мы решили рисовать их отдельно.
WBOIT, как и обычный блендинг, — это интерполяция; они не допускают того, чтобы цвет вышел за рамки смешиваемых цветов, поэтому они и используются для рендеринга прозрачных объектов. Аддитивное смешивание, насколько я знаю, рекомендуется применять для рисования источников света (частиц огня, например). Оно приводит к бесконтрольному осветлению цветов. Чем больше фрагментов смешивается, тем светлее получается результирующий цвет, вплоть до белого (в большинстве случаев). Это видно на картинке из предыдущего комментария. Единственное, что есть общего с WBOIT — это то, что нет необходимости в сортировке.
1. Если у вас тупые правила, то глупо винить тех, кто их исполняет. Виноват тот, кто их внедряет. Светлана Владимировна, конечно, красиво и пафосно всех отругала, но вина в первую очередь на ней лежит. Если это, конечно, она утвердила конкурс.
2. Сергей тоже хорош. Пытается победить в споре за счет того чтобы унизить и высмеять, вместо того чтобы спокойно аргументировать. Это всё приемы голимой демагогии, присущей политиканам и пропагандистам. На конструктивный лад топ-менеджеров это совещание точно не настроило. А только подготовило почву для еще большей грызни, интриганства и прочих прелестей корпоративной жизни.
Почему в примере «про move и лямбду» выводятся только 3 строчки в cout?
«return std::move(f);» в теле лямбды конструирует временный объект типа Foo («Foo(Foo&&)» или «Foo(const Foo&)» — не важно). Это 3-я строчка. Дальше нужно из этого временного объекта сконструировать объект f2. Значит, должна быть 4-я строчка?
Я придумал использовать GL_LINEAR, чтобы избавиться (вообще!) от одной из этих проблем — зависимости смещения от скалярного произведения dot(normal, lightDir), которое авторы статьи добавляют в шейдер. Я могу себе представить ситуацию, когда такая зависимость создает дополнительные артефакты.
Если автору использовать GL_NEAREST было удобно для статьи (и только), то он бы, может быть, написал в конце пару слов о GL_LINEAR. Я задал тот же вопрос в комментариях к оригинальной статье. Там все обсуждения велись 2-3 года назад, так что вряд ли они даже заметят. Но если ответят что-нибудь интересное, напишу здесь перевод.
Почему используется фильтр GL_NEAREST? Я так понимаю, что при использовании GL_LINEAR зигзагообразная линия на 7-м рисунке превратится в прямую, и «муаровые узоры» исчезнут? Я немного поигрался с этим примером. Если применить линейную фильтрацию:
то при небольшом смещении (bias = 0.005) муаровые узоры не появляются при любых углах освещения (я менял координату Y в переменной lightPos). И это логично, что при линейной интерполяции смещение не должно зависеть от угла освещения. Углы у теней получаются слегка скругленные, а «peter panning» из-за маленького смещения почти незаметен.
Ну, Вы уже зашли туда, где нужен объект с тремя состояниями в качестве параметра, а статья все-таки про флажки.
Автор пишет, что использовать в качестве флагов перечисления или tagged_bool — это вопрос личных предпочтений. Почитайте комментарий ARNAUD к оригинальной статье — я его тоже перевел.
А какой scheduler используется в 1-м примере?
По 2-му примеру: зачем указывать scheduler в make_count? Там создаётся фабрика sender-а, который формирует задачу по подсчёту слов в файле. Зачем ему знать о том, что его будут запускать в thread пуле? По-моему, это неправильное разделение ответственности, и конкретный scheduler нужно указать позже. И, кстати, непонятно, зачем вообще использовать senders/receivers в первой части, где подсчитываются слова. Подсчёт слов можно написать и обычным способом, и это будет гораздо более читаемо. Что хотелось бы сделать, так это взять функцию типа "count_words(string path)", сделать из неё 3 сендера в трёх строчках кода, сделать scheduler с thread пулом, и потом вызвать when_all, чтобы выполнить эти функции параллельно, внутри какого-то более сложного графа исполнения. Тогда целесообразность сендеров/ресиверов была бы более очевидной.
completion_signatures_of_t содержит сигнатуры set_value, set_stopped и set_error, которые в пользовательском коде нигде не используются. Зачем пользователю информация об этих сигнатурах? Её смысл не очевиден, и, по-моему, она выглядит как пример плохой архитектуры стандартной библиотеки, потому что требует знания внутренностей реализации, которые не используются пользователем напрямую.
Я бы её купил, если бы на сайте не требовалась регистрация с номером телефона. Пришлось скачать с торрента.
Авторам перевода спасибо за проделанную работу!
А почему на GOG не выложили?
Автор, Вы не могли бы посоветовать мемуары советских инженеров из разных десятилетий XX века? По которым можно увидеть, как работали советские предприятия и НИИ, и как всё это менялось со временем?
Идея — сделать круглый экран на руле и поворачивать интерфейс вместе с поворотами руля, чтобы интерфейс всегда стоял вертикально.
Идея звучит прекрасно, но реализация откровенно плохая. У меня, как и у многих комментаторов, выводится только предложение пересоздать профиль и потратить ещё несколько часов на анкету, чего я, естественно, делать не буду. И судя по ответам автора, они даже не собираются решать эту проблему. Им кажется, что всё так и должно работать.
Арендодателем может выступать фирма, владеющая производственными возможностями, которая может проапгрейдить ноутбук так, что с точки зрения потребителя он будет совершенно новый. Отлить новый корпус, поставить более мощную электронику, а старую использовать в других продуктах, либо продать тем, кто сможет её использовать в других продуктах. Это однозначно выгоднее существующей бизнес-модели, когда всё изделие выкидывается вместе с деталями, пригодными для использования. Вообще, конечным арендодателем может выступать условный асус.
> Арендованная - стираем в тазике пока не приедет тот-самый-специалист.
Если вас не устраивает, что специалист не приходит в течение часа, обратитесь к другой фирме. Бизнес, который не может предоставить хороший сервис, не выживает на рынке.
Есть такое явление, как копроэкономика, когда производитель сознательно снижает надёжность изделий, чтобы повысить прибыть от продажи запчастей или новых изделий. И вот меня давно мучает вопрос, почему до сих пор не появилась модель бизнеса, которая решает эту проблему, и я давно хотел задать его кому-то, связанному с ремонтом техники.
Допустим, есть некая фирма, которая предоставляет домохозяйству свою бытовую технику и электронику за ежемесячную плату (примерно так, как большинство интернет-провайдеров предоставляют роутер). Если, к примеру, ноутбук выходит из строя, то фирма за свой счёт его чинит, либо заменяет на новый, а старый разбирает на запчасти. Такая фирма будет покупать только надёжную технику, поскольку у неё достаточный уровень экспертизы, чтобы найти такую технику. Производители получат стимул делать надёжную технику, чтобы удовлетворить спрос со стороны таких фирм.
Кто-нибудь может рассказать, почему такая бизнес-модель не прижилась на рынке?
Какие все? В Азербайджане одна ТЭЦ есть только в Баку, насколько я знаю, и к ней подключён не весь город. В Грузии и в Армении центрального отопления вообще нет.
Непонятно, почему в Qt по умолчанию происходит вывод в рендербуфер с линейным цветовым пространством, и для поддержки sRGB приходится настраивать QOpenGLWidget.
В своём рабочем проекте я это тоже исправил (приятно открывать для себя мир; у нас ни одного синьора в команде, вот и приходится наступать на грабли:)). Там тоже улучшился антиалиасинг и фильтрация текстур. Ещё раз спасибо!
Если всё ещё интересно, как выглядит аддитивный блендинг с нормальной гамма-коррекцией, то вот, что у меня получилось:
Внизу слева обычный аддитивный блендинг (Вы правы, в белый мы теперь вываливаемся медленнее), справа — с экспозицией
1.0 - exp(-0.8*c).Теперь пара слов для тех, кто ещё считает, что WBOIT — это аналог аддитивного блендинга, с той же областью применения. Вот на этой картинке сверху видно, что тёмные цвета (у длинных радиальных треугольников с жёлтыми кромками) при аддитивном блендинге практически не влияют на результирующий цвет (именно потому что они тёмные, т.е. имеют маленькие числовые значения). При использовании WBOIT их вклад в результирующий цвет пропорционален значению opacity, они реально могут затемнить свой кусок экрана. Мы вычисляем взвешенную сумму цветов, значит, результат никогда не выйдет за пределы цветов, которые мы смешиваем. Это позволяет использовать метод для рендеринга прозрачных объектов. Аддитивный блендинг (хоть с экспозицией, хоть без) подходит для рендеринга источников света. Результат может выйти за пределы смешиваемых цветов, как в тёмную, так и в светлую сторону.
У меня вышло, что аддитивный блендинг с экспозицией по сравнению с WBOIT — это минус 2 текстуры, минус 1 фреймбуфер, и шейдер конечного постпроцессинга чуть попроще. Положа руку на сердце, это не сильно упрощает рендеринг. К тому же, коэффициент экспозиции надо подбирать для каждой конкретной сцены.
WBOIT, как и обычный блендинг, — это интерполяция; они не допускают того, чтобы цвет вышел за рамки смешиваемых цветов, поэтому они и используются для рендеринга прозрачных объектов. Аддитивное смешивание, насколько я знаю, рекомендуется применять для рисования источников света (частиц огня, например). Оно приводит к бесконтрольному осветлению цветов. Чем больше фрагментов смешивается, тем светлее получается результирующий цвет, вплоть до белого (в большинстве случаев). Это видно на картинке из предыдущего комментария. Единственное, что есть общего с WBOIT — это то, что нет необходимости в сортировке.
Вы это имели в виду?
2. Сергей тоже хорош. Пытается победить в споре за счет того чтобы унизить и высмеять, вместо того чтобы спокойно аргументировать. Это всё приемы голимой демагогии, присущей политиканам и пропагандистам. На конструктивный лад топ-менеджеров это совещание точно не настроило. А только подготовило почву для еще большей грызни, интриганства и прочих прелестей корпоративной жизни.
«return std::move(f);» в теле лямбды конструирует временный объект типа Foo («Foo(Foo&&)» или «Foo(const Foo&)» — не важно). Это 3-я строчка. Дальше нужно из этого временного объекта сконструировать объект f2. Значит, должна быть 4-я строчка?
Если автору использовать GL_NEAREST было удобно для статьи (и только), то он бы, может быть, написал в конце пару слов о GL_LINEAR. Я задал тот же вопрос в комментариях к оригинальной статье. Там все обсуждения велись 2-3 года назад, так что вряд ли они даже заметят. Но если ответят что-нибудь интересное, напишу здесь перевод.
то при небольшом смещении (bias = 0.005) муаровые узоры не появляются при любых углах освещения (я менял координату Y в переменной lightPos). И это логично, что при линейной интерполяции смещение не должно зависеть от угла освещения. Углы у теней получаются слегка скругленные, а «peter panning» из-за маленького смещения почти незаметен.
Так почему не использовать линейную фильтрацию?
Автор пишет, что использовать в качестве флагов перечисления или tagged_bool — это вопрос личных предпочтений. Почитайте комментарий ARNAUD к оригинальной статье — я его тоже перевел.