Хмм... Выглядит очень неплохо... Видимо, осталось ждать нам прозрачности не так долго (по секрету скажу, что *очень* ее жду - мне она нужна для проги, дабы Type1 шрифты размером порядка 10-12 пунктов рендерились нормально...)

а разве нужно изменять X протокол? не достаточно ли просто рисовать текст с антиалиасингом всегда?

> не достаточно ли просто рисовать текст с антиалиасингом всегда?

Спасибо, не надо :)))

всегда -- медленно

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

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

А ты подумай, как это будет через сеть. Не у всех ведь еще >=100Мbit...

Ребята, нашли из-за чего флеймить. Пусть анонимус пойдет и сделает RTFM. И еще FAQшки всякие, типа XFree86шных. Больше всего меня добивает фраза "если приложение вывело текст то подразумевается для его прочитают и оно не будет через сотую долю секунды рисовать на его месте новый"... Человек видимо никогда не видел, например, индикаторов времени (с милисекундами), которые должны обновляться максимально часто, дабы юзер все время мог видеть наиболее текущее время. По поводу "просто рисовать текст текст с антиалиасингом"... Посмотри, например, как это сейчас сделано в ClanLib/X11, ужаснись и забудь. Тормозит просто безбожно.

а гдее ссылка на FM?

индикаторов с милисикундами (!!) я не видел и вряд ли они нужны в принципе - максимум с десятыми долями. Честно говоря я ещё несколько раз перечитал эту фразу (о приложении) и не смог понять greyкошка, почему она его добивает

Абысняю. Есть у тебя MIDI-сиквенсер. Ты - композитор, пишешь музыку в нем. В этом сиквенсере есть такая вещь, как индикатор времени (в куче различных форматов, начиная с примитивных час:мин:сек:доли сек до чего-нибудь в стиле трек:такт:доля такта:тик). Вот этот индикатор должен обновлять максимально часто. Почему? Потому, что при воспроизведении песенки, например, ты можешь в любой момент нажать паузу, например, и при этом индикатор должен показывать именно в тот момент самое точное показание. Это очень важно, особенно при синхронизации MIDI с аудио, например... Если пример номер один человека не вдохновил - тогда пример номер два. Просто самый что ни на есть банальный скроллинг. Когда текст скроллится страницами, его же перерисовывают, но никто его не читает... Или, например, бегущая строка - она же тоже очень часто перерисовывается...

интересно, а нельзя ли эти цифирьки выводить максимально точно в момент нажатия той самой паузы (то есть чтобы они максимально точно отображали сам момент нажатия)? При этом не надо будет столько процессора тратить, да и антиалиасинг можно включить -- цифирьки покрасивше будут... Как говорят, just my $0.02... Впрочем, это к делу (subj) не относится. Да, тоже не по делу -- может, кто подскажет, как в xfree 4 настроить русский _её_ средствами (без modmap)? Уж очень неудобно на Alt давить всё время, а вроде бы всё что надо заложено...

а anonimousы-то все разные :) гда тут регистрация ??

вообще это идея -- во время скролинга текст выводить без антиалиасига, а при остановке -- с. :)) как это микрософт до этого не додумалась .... :)

Ну и как ты предлагаешь на уровне протокола отличать скроллинг от чего-то еще?

Циферки *надо* обновлять максимально часто. Они очень важны - и их надо рисовать практически на полный экран (так называемое Big Time) - дабы, если например ты записываешься с группой в студии, то все члены группы метров за пять от одного монитора могли смотреть на этот индикатор времени. Антиалиасинг там не нужен в принципе (цифры большие и их вообще не нужно антиалиасить), а лучше за те 27 рендерингов одной и той же строки для антиалиасинга показать 27 раз новые показания индикатора.

Да будет флейм... г. Бог 8)

Мне кажется ты забыл про инерционность человеческого глаза (~0.1 c), так что выводить на экран больше 10 - 15 показаний в секунду, смысла не имеет.

насчёт скроллинга это был сарказм (для того кто не понял) -- просто greycat приводил пример начсёт того, когда не надо выводить текст с антиалисингом.

Во, блин, народ, я просто тащусь... Эх, пардон за anonymous -- я зарегистрился, тока пароль не помню :) (mjt) -- найдём. Ладно. Итак.

- практически _не_ требуется на уровне протокола включать этот антиалиасинг. Его можно иметь возможность _отключать_ в некоторых экзотических случаях. Пример тому -- те же винды, где АА задаётся на уровне "операционки", а не каждым приложением (не надо про "невиндовые" шрифты типа адобовских).

- растровые шрифты действительно сложно подвергать АА, и именно на это должна уходить масса времени. С векторными всё гораздо лучше (те же винды практически -- MS Sans Serif не "алиасится")

- действительно, для реализации этого АА требуется переработка протоколов обмена с font-server'ом (и только), однако на большинстве машин он не используется (не надо тыкать в RedHat pls). Решение тривиальное -- если fs (fontserver) поддерживает АА, прекрасно, если нет -- шрифты с него не алиасим.

- очень малое распространение получили нерастровые шрифты (у растра них есть куча своих плюсов), и это здесь проблема. Но не с протоколами.

- заявление graycat по поводу такой частоты смены цифр (это я "внёс предложение") просто, прошу прощения, смешно. Ребята, блин, ну для чего надо эти цифры всё время изменять?! "За уши" достаточно, "за глаза", чтобы _после_ нажатия "паузы" на экране отобразился момент времени этого нажатия (и соответственно времени останова). В остальное время _вообще_ не надо этот таймер показывать! Если речь идёт о том, чтобы наоборот найти точку, соответствующую времени, то, блин, наберите вы это точное время со всеми там милли-микро- и скажите "встань на эту позицию". И всё. С такой скоростью бегущие числа всё равно в принципе разглядеть невозможно, не то что бы поймать момент... Между прочим, при занятии проца перерисовкой он не сразу и на нажатие-то среагирует...

Вот так. "Поумничал". Прошу прощения, я не нарочно, и не такой уж я "заумный" :)

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

Хм.. При скроллинге действительно надо будет AA убирать и я это уже где то (не в Х) видела. И при чем тут протокол?! софтина сама получает scroll event и рендерит текст без AA (чтонть вроде X86SetAAMode(FALSE) :) ).

Софтина не должна рендерить сама никакого текста - это будет *жутко* долго. Предлагаемый вариант - по сути дела и есть изменение протокола. Опять же советую всем не забывать о том, что есть: а) иксы по сети (да хоть по модему) б) хардверные X-терминалы.

Может, кому не лень будет, кинете сюда, на хрена АА вообще нужен? Как-то "по умолчанию" народ считает, что без AA -- как без рук. Мне, например, он всегда мешает. Может, кто объяснит, чем "размытые" буквы лучше "зубчатых"?

Ну и по-поводу выведения того несчастного таймера. Если он действительно - причина торможения, то можно каждую из цифр отрендерить в pixmap и набирать число из pixmap'ов, соотвествующих цифрам числа. pixmap'ы храняться на сервере, и поэтому по сети будут только передаваться команды ("покажи pixmap такой-то").