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

I>bowser applications всё вытесняют.



Bowser вытесняЭ!

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

CC>>>Потому что хром его даже на просмотр не смог загрузить
P>>Ну разумеется. Он пытается вгрузить всё, а нужна частичная подгрузка и виртульный скроллинг.
CC>Редактор в FAR, которому надо файл таки менять а не просто показывать, тем не менее справляется.

С мест сообщают, что фар дохнет уже на 56мб
http://rsdn.org/forum/setup/8421206.1

Автор: Pavel Dvorkin
Дата: 04.12.22

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

P>С мест сообщают, что фар дохнет уже на 56мб
P>http://rsdn.org/forum/setup/8421206.1

Автор: Pavel Dvorkin
Дата: 04.12.22

Не на 56мб а на весь файл в одну строку длиной в 56мб.
Ради интересу побырому, на коленке, сделал из своих гигабайтных csv 56метровый файлик в одну строку путём truncate и замены 0x0a -> 0x20, и открыл его в редакторе Far2 1807.
При открытии Far призадумался секунд так на десяток но потом таки открыл и всё показал, ProceXp показывал что всё это время он что то делал внутри colorer.dll.

Так что думается что у него там colorer своими регекспами пытался этот пц распарсить.

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

P>С мест сообщают, что фар дохнет уже на 56мб
P>http://rsdn.org/forum/setup/8421206.1

Автор: Pavel Dvorkin
Дата: 04.12.22

Там скорее с ОЗУ и/или производительностью узкое место. Иногда нет времени ждать, чем позволить себе больше памяти или ядер.
Если временно отключить Colorer, то редактор фары существенно бафает на произодительность.

В папке плагина FarColorer\bin есть hrcsettings.xml с настройками.
maxlinelength (5000) отвечает за максимальную длину строки, backparse (6000) за количество строк от начала.
Мне обычно приходилось их увеличивать дописыванием ноликов, чтобы красить длинные строки (500000) и многострочные файлы(600000).

Без Colorera жизни на Марсе нет.

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

A>Иногда нет времени ждать, чем позволить себе больше памяти или ядер.
Ээээ? чо?

A>Если временно отключить Colorer, то редактор фары существенно бафает на произодительность.
Как раз colorer там и жевал это всё.

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

CC>Ээээ? чо?
Многие считают "зависло", если приложение не отвечает пару минут. Но дать приложению ядер, частоты или памяти многие не считают. А это напрямую влияет на "зависло".

CC>Как раз colorer там и жевал это всё.
Я знаю.

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

S>Хмм. Неужто и плавный зум обеспечит? С каких пор у нас TextOut и его друзья научились делать зум на 110% без рывков ширины?

О каких рывках ширины ты сейчас говоришь?

	Скрытый текст

Здравствуйте, Marty, Вы писали:
M>О каких рывках ширины ты сейчас говоришь?
Выглядит неплохо. Это в каких кеглях выведено?

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

M>>О каких рывках ширины ты сейчас говоришь?
S>Выглядит неплохо. Это в каких кеглях выведено?

Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится. Так что

S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.

А эти рассуждения чем отдают?


ЗЫ некоторая неравномерность думаю объясняется тем, что я не брал проценты от текущего размера, а тупо в цикле уменьшал на константу.

ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами

ЗЫЫЫ Вывел с шагом *=0.97 — на самом деле — некоторая неравномерность таки есть, но имхо отрендерить PDF не помешает

	Скрытый текст

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

M>Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится.
Дело не в третьекласснике. Дело в конкретных размерах. Пусть будет в пикселах — какие параметры использовались?

M>А эти рассуждения чем отдают?
Давайте сначала получим картинку.

M>ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами

M>ЗЫЫЫ Вывел с шагом *=0.97 — на самом деле — некоторая неравномерность таки есть, но имхо отрендерить PDF не помешает
Есть несколько нюансов. Возможно, они уже устранены, а я отстал от жизни, но это маловероятно.

M>

	Скрытый текст
	M>Image: 2022_11_02_17_12_48_image.png

Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится.
Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.

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

M>ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами
Очень хорошо на самом деле, в разы лучше чем более новомодные реализации в DirectWrite

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

S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?

java ME
java Applet
java SE
java web start
java EE

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

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

S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?

Нужны наборы стандартных контролов уровня mvs хотя бы, и скорости на больших наборах данных.
Иначе вся эта хрень подходит только для онлайн магазинов и всякого такого, а разные там ansys, компас, солидворкс, 3dmax — Туда никогда не переедут.

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

M>>Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится.
S>Дело не в третьекласснике. Дело в конкретных размерах. Пусть будет в пикселах — какие параметры использовались?

Было

        lf.lfOutPrecision    = OUT_OUTLINE_PRECIS;
        lf.lfClipPrecision   = CLIP_DEFAULT_PRECIS;
        lf.lfQuality         = ANTIALIASED_QUALITY;
        lf.lfPitchAndFamily  = DEFAULT_PITCH | FF_DONTCARE;

	Скрытый текст

Перечитал доку — оказалось, что ANTIALIASED_QUALITY работает только если глобальная настройка в системе включена


Поиграл, сделал

        lf.lfOutPrecision    = OUT_OUTLINE_PRECIS;
        lf.lfClipPrecision   = CLIP_DEFAULT_PRECIS;
        lf.lfQuality         = CLEARTYPE_QUALITY;
        lf.lfPitchAndFamily  = DEFAULT_PITCH | FF_DONTCARE;

	Скрытый текст

Стало поприятнее

S>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится.
S>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.

Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу

Скачки есть, но фатального ничего не вижу
Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм

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

M>Стало поприятнее
Ну, как я и ожидал — чудес не бывает.

S>>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится.
S>>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.

M>Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу

M>Скачки есть, но фатального ничего не вижу
И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство.
Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
И когда вы делаете ей зум-фактор 80%, то пользователь ожидает, что все строчки станут короче на 20%, а не так, что кто-то — на 15%, а кто-то — на 22%.
M>Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм
Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.
Почитайте классику: http://rastertragedy.com/
Именно поэтому Adobe рендерят текст сами, без помощи системы.

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

M>Перечитал доку — оказалось, что ANTIALIASED_QUALITY работает только если глобальная настройка в системе включена
Вроде как нет, по крайней мере при достаточно больших размерах шрифта ANTIALIASED_QUALITY делает края заметно сглажеными даже когда cleartype в системе выключен

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

M>>Стало поприятнее
S>Ну, как я и ожидал — чудес не бывает.

Особо ничего не поменялось, просто отображение шрифтов стало более приятным глазу


S>>>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится.
S>>>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.

M>>Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу

M>>Скачки есть, но фатального ничего не вижу
S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство.
S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
S>И когда вы делаете ей зум-фактор 80%, то пользователь ожидает, что все строчки станут короче на 20%, а не так, что кто-то — на 15%, а кто-то — на 22%.
M>>Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм
S>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.

Я просто напомню:

S>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.

Слушай, мне, если честно, хотелось спросить, что ты съешь — галстук или шляпу, но я не стал обострять, думал, до тебя дойдёт и ты сам признаешься в своей неправоте. Хотя бы и не публично, а для себя. Но ты сам полез в залупу.

            // Выбираем из масштабной сетки (подсмотрел в гугл хроме)

            std::array<unsigned, 14> scales = { 500, 250, 175, 150, 125, 110, 100, 90, 80, 75, 67, 50, 33, 25 };

            textoutTestFontParams.height = 6; // 2.7

            for(auto scale : scales)
            {
                auto tmpFontParams = textoutTestFontParams;
                tmpFontParams.height = scale*textoutTestFontParams.height / 100;
            
                std::string text;
                umba::StringRefCharWriter writter = text;
                umba::SimpleFormatter uss(&writter);
           
                uss << textoutTestFontParams.fontFace << ": " << scale; // textoutTestFontParams.height;

                int fontId = pDc->selectNewFont( tmpFontParams );
                pDc->textOut( textoutTestPos, fontId, ColorRef{32,32,32}, text );
                textoutTestPos.y += tmpFontParams.height;
            }

	Для 6ки

	Для 2.7 — выбирал, чтобы не особо было кратно 6ке

Посиди с линейкой перед экраном, поизмеряй, посчитай-посравнивай.


S>Почитайте классику: http://rastertragedy.com/
S>Именно поэтому Adobe рендерят текст сами, без помощи системы.

Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку.
Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.

S>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.

S>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.

ЗЫ Понимаю, что требовать съесть шляпу от тебя — бесполезно

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

M>>Перечитал доку — оказалось, что ANTIALIASED_QUALITY работает только если глобальная настройка в системе включена
CC>Вроде как нет, по крайней мере при достаточно больших размерах шрифта ANTIALIASED_QUALITY делает края заметно сглажеными даже когда cleartype в системе выключен

Согласен, на больших размерах GDI выглядит лучше, чем GDI+, в котором я не сделал

m_g.SetTextRenderingHint(Gdiplus::TextRenderingHintAntiAlias);

Но на мелких размерах GDI был убог, пока этот топик не напряг меня почитать доки повнимательнее

ЗЫ GDI+ на больших размерах стал получше, но на всех размерах стал мыльным каким-то. GDI гораздо приятнее выглядит

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

M>Согласен, на больших размерах GDI выглядит лучше, чем GDI+
Рендеринг шрифта в GDI+ просто ужасен.

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


M>Я просто напомню:
M>

S>>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.

M>Слушай, мне, если честно, хотелось спросить, что ты съешь — галстук или шляпу, но я не стал обострять, думал, до тебя дойдёт и ты сам признаешься в своей неправоте. Хотя бы и не публично, а для себя. Но ты сам полез в залупу.

M>Посиди с линейкой перед экраном, поизмеряй, посчитай-посравнивай.
Ну что за детский сад — экран, линейка.
Берём текст, берём шрифт, берём GetTextExtentPoint32.
Сравниваем:

Текст	Width, Times New Roman 12pt	Width, Times New Roman 24pt	Ratio	Delta
The Quick Brown Fox Jumps over the Lazy Dog	295	612	2.08	22px
Иван Родил Девчонку, Велел Тащить Пелёнку.	320	647	2.02	7px
The Text Width сan Vary Quite Dramatically	269	569	2.12	31px

M>Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку.
Хм. Вот эта табличка иллюстрирует мою цитату, которую вы любезно привели выше. Вы готовы привести формулу для ширины текста в 24 кегле, основываясь на его ширине в 12м?

M>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.
Прекрасно заметят, когда текст, который был выровнен, начнёт плавать при кручении колёсика зума.

M>

S>>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.

M>

S>>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.

M>ЗЫ Понимаю, что требовать съесть шляпу от тебя — бесполезно
Нет, отчего же. Но для начала нужно всё-таки опровергнуть моё утверждение