Здравствуйте, VladD2, Вы писали:

VD>Ни у IPS, ни у VA не может быть честной яркости. Там одно мошенничество. Они делают local dimming чтобы достичь указываемой яркости, а замеряют её на белой и черной точках в разных частях экрана. Реальный контраст есть только у OLED-а.

Яркость OLED- такое же мошенничество, как контраст local dimming IPS/VA.

Здравствуйте, SkyDance, Вы писали:

EP>> лично для меня является недостатком, так как предпочитаю иметь больше вертикального пространства — для чтения/просмотра кода и документов.
SD>Вы, случаем, не из тех адептов, что требуют исходный код форматировать под "стандартные 80 колонок"?

Нет, а как это вообще связанно?
Типа строчки такие длинные что только на сверхшироком мониторе влезают?
Или перенос на следующую строчку как-то значимо увеличит общее количество строк?

В любом случае, что с переносом, что без, файлы на сотни, а то и тысячи, строк не редкость. И вот их удобнее читать/просматривать при большем вертикальном разрешении и физическом размере
Или ты из тех адептов которые требуют каждую функцию в отдельный файл сохранять?

В>>Общепринято сейчас 120 символов.
CC>Где общепринято?

Сообществом. Можешь загуглить почему у код анализаторов стоит именно столько.

В>>Везде читаемый, в противном случае, нужно искать проблему в коде.
CC>Таки походу адепт, да.

Почитай про Codesmels что ли.

Здравствуйте, Владислав, Вы писали:

В>>>Общепринято сейчас 120 символов.
CC>>Где общепринято?
В>Сообществом.
Каким сообществом?

В>>>>Общепринято сейчас 120 символов.
CC>>>Где общепринято?
В>>Сообществом.
CC>Каким сообществом?

Да не важно, почитай книжек что ли хороших, про рефакторинг и качество кода, для начала.

Здравствуйте, Владислав, Вы писали:

В>>>>>Общепринято сейчас 120 символов.
В>Да не важно, почитай книжек что ли хороших, про рефакторинг и качество кода, для начала.

Книжка про качество кода где говорится что должен быть жёсткий лимит отправляется в топку.
Сколько я за годы видел coding standards с подобными жёсткими рамками — все только ухудшали читаемость.

В>>>>>>Общепринято сейчас 120 символов.
В>>Да не важно, почитай книжек что ли хороших, про рефакторинг и качество кода, для начала.
CC>Книжка про качество кода где говорится что должен быть жёсткий лимит отправляется в топку.
CC>Сколько я за годы видел coding standards с подобными жёсткими рамками — все только ухудшали читаемость.

а чё это за код такой, что в 120 символов не влазит? есть пример?

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>а чё это за код такой, что в 120 символов не влазит? есть пример?
Есть конечно.
Ткнул в первую попавшуюся длинную строку в первом попавшемся файле — 253 символа. В экран влезет ещё сотня-полторы на глаз.

Оформление кода должно определяться читабельностью для человека а не просто тупо принудительной цифрой с потолка.

САД>>а чё это за код такой, что в 120 символов не влазит? есть пример?
CC>Есть конечно.
CC>Ткнул в первую попавшуюся длинную строку в первом попавшемся файле — 253 символа. В экран влезет ещё сотня-полторы на глаз.

CC>Оформление кода должно определяться читабельностью для человека а не просто тупо принудительной цифрой с потолка.

так есть пример такого кода? я себе слабо представляю читабельной строку из 253 символов

EP>Или перенос на следующую строчку как-то значимо увеличит общее количество строк?

Ага. Представь, что каким-то случайным образом джуниор девелопер получил задание сделать форматтер кода. Само по себе задание несложное, джуниор отлично справится. Но сделать reflow он по-быстрому не смог (а надо было по-быстрому, т.к. каждые полгода компания требует "realized impact"). В итоге форматтер начинает внедряться "as is". Поскольку reflow там нет, каждый вызов функции (или, еще хуже, заголовок функции) из 1-2 строчек превращается в узенькую колоночку из десятка строчек:

было:

my_fun(Arg1, Arg2, Arg3, Arg4) when is_atom(Arg1) ->


форматтер:
my_fun(
Arg1,
Arg2,
Arg3,
Arg4)
when
is_atom(Arg1)

Попытки грамотных инженеров сказать "парни, ну так же нельзя, вы посмотрите, это противоречит всем сложившимся стандартам, включая стандартную библиотеку языка, и даже нашему собственному коду". В ответ — бредятина на тему "любая автоматизация форматирования лучше, чем отсутствие таковой". За дальнейшую попытку непринятия этого форматтера мне в итоге досталось "с занесением в трудовую книжку".

Так что теперь чтоб такой код читать, хошь не хошь, а монитор нужно переворачивать в вертикальную ориентацию.

SD>

SD>было:

SD>my_fun(Arg1, Arg2, Arg3, Arg4) when is_atom(Arg1) ->


SD>форматтер:
SD>my_fun(
SD> Arg1,
SD> Arg2,
SD> Arg3,
SD> Arg4)
SD> when
SD> is_atom(Arg1)

SD>Попытки грамотных инженеров сказать "парни, ну так же нельзя, вы посмотрите, это противоречит всем сложившимся стандартам, включая стандартную библиотеку языка, и даже нашему собственному коду". В ответ — бредятина на тему "любая автоматизация форматирования лучше, чем отсутствие таковой". За дальнейшую попытку непринятия этого форматтера мне в итоге досталось "с занесением в трудовую книжку".

SD>Так что теперь чтоб такой код читать, хошь не хошь, а монитор нужно переворачивать в вертикальную ориентацию.

когда аргумента 4, как в примере, строка будет не особо большой длинны, и вполне умещается в 120 символов, не требуя переносов,
а вот если аргументов более 4х, то тут прослеживается целая куча проблем и вопросов к дизайну

САД>а вот если аргументов более 4х, то тут прослеживается целая куча проблем и вопросов к дизайну

Каких именно вопросов?
В Erlang очень удобно "раскрыть" все структуры прямо в заголовке функции. Например, так:

handle_call({count, BumpUp}, _From, #state{accumulator = Current, log = ShouldLog} = State) ->

Это правильный, легко читаемый и понимаемый дизайн. Если нужно матчить больше частей структуры State, можно записать так:

handle_call({count, BumpUp}, _From, 
    #state{accumulator = Current, log = ShouldLog, more = More, match = Match, some = Some} = State) ->

Вот только недоделанный форматтер не умеет reflow. Поэтому получится... вот так:

handle_call({
        count, 
        BumpUp
    }, 
    _From, 
    #state{
        accumulator = Current, 
        log = ShouldLog, 
        more = More, 
        match = Match, 
        some = Some
    } = State)
->

Что прям стихами скажу: "Хошь не хошь, а монитор перевернешь".

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>так есть пример такого кода?
Тебе уже отвечено что есть.
И нет, я не стану публиковать куски из closed source ради срачика в интернетах.

САД> я себе слабо представляю читабельной строку из 253 символов
Я там и в 310 символов строку нашёл
Всё читабельное.

Здравствуйте, Артём, Вы писали:

Аё>Яркость OLED- такое же мошенничество, как контраст local dimming IPS/VA.

Странное заявление. У моего лаптопа Dell экран OLED ярче чем на макбуке, под солнцем можно работать.

Здравствуйте, VladD2, Вы писали:

VD>Ни у IPS, ни у VA не может быть честной яркости. Там одно мошенничество. Они делают local dimming ....

Это ты про динамическую контрастность. Ты не прав. Я однажды работал за VA, притом за относительно дешёвым монитором. Контрастность там действительно крутая была. Недостатков у VA хватает, но контраст — это точно его достоинство. За тем дешёвым монитором с графикой было плохо работать, однако текст и чертежи — это про него.

Поэтому я домой купил первый IPS, он мне тогда в больше чем 700 евро обошёлся. И в итоге оказалось, что не доплатил — дейсвительно хорошие модели стоили от 1000 евро. Когда купил, долго и сильно мучился с настройкой — не устраивали паразитные оттенки в разных частях монитора. Я тогда пытался в фотошопе цвета на фотках править — глаза от неравномерности цветопередачи монитора аж вытекали.

ЗЫ: на OLED меня пока жаба душит — таки дороговато.

Здравствуйте, aik, Вы писали:

Аё>>Яркость OLED- такое же мошенничество, как контраст local dimming IPS/VA.

aik>Странное заявление. У моего лаптопа Dell экран OLED ярче чем на макбуке, под солнцем можно работать.

Телек LG C2 — вроде бы идеал для игр, не?

7.7
SDR Brightness
Real Scene Peak Brightness
422 cd/m²
Peak 2% Window
427 cd/m²
Peak 10% Window
435 cd/m²
Peak 25% Window
397 cd/m²
Peak 50% Window
372 cd/m²
Peak 100% Window
186 cd/m²
Sustained 2% Window
407 cd/m²
Sustained 10% Window
413 cd/m²
Sustained 25% Window
377 cd/m²
Sustained 50% Window
353 cd/m²
Sustained 100% Window
178 cd/m²
Automatic Brightness Limiting (ABL)
0.053

https://www.rtings.com/tv/reviews/lg/c2-oled

178 cd/m², Карл!

Напомню, типичная яркость нормального без претензий на HDR IPS 350 cd/m².

Аё>178 cd/m², Карл!

На 100% заливке. Мне сложно представить сценарий, где мне нужно показывать белый экран, да еще и с полной яркостью, хоть сколь-нибудь продолжительное время. Да и вообще по стандарту хорошо освещенного помещения монитор калибруют на 120 кд/м2. Так что тут даже с запасом.

Здравствуйте, SkyDance, Вы писали:

SD>На 100% заливке. Мне сложно представить сценарий, где мне нужно показывать белый экран, да еще и с полной яркостью, хоть сколь-нибудь продолжительное время. Да и вообще по стандарту хорошо освещенного помещения монитор калибруют на 120 кд/м2. Так что тут даже с запасом.

Вообще-то это "доистоический HDR" 2000г — но где умели работать и со светом и даже "устаревшими" светофильтрами на обычной пленочной камере и сделали бютжетный фильм топовым и у Вин Дизеля как и у Ридика карьера вверх пошла. Pitch Black 2000г, просто самое начало фильма — неадекватные яркие вспышки, на DLP проекторе выглядят просто ослепляюще. Далее в фильме "неадекватные засветы" ибо несколько солнц одновременно на небе и т.п. А реально — там какой-то супер режиссер или кто ему помогал, при небольшом бюджете выдать шедевр даже по картинке! По сюжету и актерам(неизвестный на то время Вин Дизель, видимо сделал карьерный прыжок на этом фильме) — там и так топ все, стоит посмотреть и на девайсах где реально много яркости и где очень черный — ибо фильм так снят, либо планета с 3 солнцами либо полная темнота. Может от этого фильма HDR и зародилось — не хватило динамического диапазона режиссеру и он пошел искать как сделать круче.

P.S. мониторам такие стандарты нафиг не нужны — типа HDR1000, от HDR600 просто никто не отличит. Милипизерная диагональ и смысла что экран будет иметьчуть больше яркости — около нулевая. Но мониторам нужно хотябы HDR400 — просто обычный хороший монитор с адекватной подсветкой такое выдает.

__>Вообще-то это "доистоический HDR" 2000г — но где умели работать и со светом

Я не про HDR, а про полиграфию и про обработку изображений. Там 120 кд/м2 — стандарт.

То что бывает всякий там HDR1000, это, конечно, здорово, но там редко нужно полноэкранный белый.
Лично на мой взгляд OLED (и в теории microLED — но на практике я их не видел) куда лучше любого LCD, даже если яркость 100% заливки у него ниже.

__> Но мониторам нужно хотябы HDR400 — просто обычный хороший монитор с адекватной подсветкой такое выдает.

В теории у моего odyssey g9 такое есть, но на практике оно не работает (только зря полосы на экране кажет).

Здравствуйте, SkyDance, Вы писали:

Аё>>178 cd/m², Карл!

SD>На 100% заливке. Мне сложно представить сценарий, где мне нужно показывать белый экран, да еще и с полной яркостью, хоть сколь-нибудь продолжительное время.

Мне сложно представить сценарий, где мне нужно показывать скринсейвер на чёрном фоне как в торговом зале, дома хоть сколь-нибудь продолжительное время.