При использовании масштабирования в Windows 10 (125%) шрифты в Ace Stream Engine размытые:
Если включить настройки совместимости для ace_engine.exe, то шрифты выглядят как надо:
Но проблема в том, что при обновлении или переустановке программы параметры совместимости приходится выставлять вручную заново (могут сбрасываться).
Можете сделать адекватное масштабирование для Ace Stream Engine (либо отключить его вовсе)? Не думаю, что это составит много труда, ведь интерфейс у него — обычное окно с текстом и кнопками. Либо же добавить флаг для запуска с отключенным масштабированием (либо масштабированием в режиме совместимости).
Как-то неохотно здесь отвечают
Могли хотя бы ответить, планируется ли исправление масштабирования или нет. Все-таки 2017 год на дворе, а некоторые разработчики все еще выпускают софт с мыльным интерфейсом. Непорядок, тем более исправляется данный недочёт на раз-два.
А если серьезно, то у задач при разработке софта есть разный приоритет.
И как бы кому не хотелось обратного, но малоактуальные задачи вроде “мыльного интерфейса” при нестандартном масштабировании, или “добавление галочки” в инсталлятор - имеют нижайший приоритет.
Неправда, Майки постепенно выпиливают старый интерфейс, заменяя его новым, но одно дело переделать интерфейс в целой ОС, другое — добавить пару строчек в [b]manifest[/b] программы для корректной поддержи масштабирования.
И как бы кому не хотелось обратного, но малоактуальные задачи вроде "мыльного интерфейса" при нестандартном масштабировании, или "добавление галочки" в инсталлятор - имеют нижайший приоритет.
Понятное дело, что это не первостепенные задачи, но и в реализации они много времени не занимают. Ладно, галочка в инсталляторе, хотите встраивать своё расширение "по-умолчанию" — ваше право. Но в чём проблема масштабирование корректное сделать? Дело пяти минут — добавить поддержку [b]DPI-Aware[/b]. Сколько не общался с разработчиками софта, все правят мелкие недочёты [b]попутно[/b] с более серьёзными багами, и только у вас на любое замечание позиция — «у нас есть дела поважнее». Неужели потраченные 5-10 минут на исправление масштабирования, так застопорят разработку программы?
Все когда-нибудь случается в первый раз. “Другие разработчики” вольны распоряжаться своим временем так, как считают нужным, у нас - иначе. Тем более, что эти “мелкие недочеты” никак не препятствуют нормальной работе нашего софта.
Из более-менее документированных - просто запустить консольную версию движка без параметров (%appdata%\ACEStream\engine\ace_console.exe в случае Windows). Ключи /по крайней мере, часть/ перечисленные там есть в вики.
Если кратко - это специальный механизм для обмена сообщениями между расширением браузера и пользовательским приложением (в нашем случае - движок Ace Stream). До недавнего время “Native messaging” был включен только для гуглохрома, а теперь, в рамках отказа от NPAPI плагина - и для ФФ.
Куда сохраняется по умолчанию кэш AceStream? У меня только один Локальный диск (С), но если, к примеру, у меня будет второй Локальный диск (D), куда по умолчанию будут кэшироваться файлы?
Если использовать ОЗУ для кэширования, то какой рекомендуете задать оптимальный объем кэша в ОЗУ для комфортного просмотра?
Почему при использовании ОЗУ для кэширования все равно создается папка acestream_cache с файлом .lock внутри?
Как избежать создания папки acestream_cache при использовании ОЗУ для кэширования?
Можно ли задать удаление папки acestream_cache при выключении движка?
Можно ли в acestream.conf прописать директорию для кэша? Каким параметром?
По умолчанию кеша на диске как минимум два, на самом деле - один создается при запуске броадкаста (.AceStream/Streaming), путь для второго (acestream_cache) - задается при установке приложения, сменить можно через ГУИ, в настройках. Под виндой управление кешем загрузки/плеера отличается от “нормальных” ОС, потому, AFAIK, ключа для смены acestream_cache нет - только ручная правка playerconf.pickle.
Рекомендуем - не задавать вообще, программа сама его рассчитает исходя из обьема ОЗУ в системе.
3,4,5. Создается как часть процесса инициализации движка, “избежать” и “удалить” - никак, по крайней мере до тех пор, пока в этом не появится какой-то практический смысл.
Можно, " --cache-dir", но не в случае винды и кеша загрузки.
Рекомендуем - не задавать вообще, программа сама его рассчитает исходя из обьема ОЗУ в системе.
Где-то читал, что размер кэша в ОЗУ по умолчанию задаётся в 200 Мб (если не использовать –live-mem-cache-size), это так или информация устарела?
Сейчас проверил, без установки параметра –live-mem-cache-size используется около 180 Мб ОЗУ, и при установке размера кэша в 512 Мб используются те же 180 Мб. Я правильно понимаю, что алгоритм кэширования в любом случае один и тот же, а параметр –live-mem-cache-size только задает предел, за который кэшу нельзя вылезать?
В бете появилась возможность настраивать кэширование в ОЗУ через GUI. Вы оставите возможность включать кэширование в ОЗУ через файл acestream.conf? Просто некоторым так удобнее.
Говорят, что постоянное кэширование на SSD может быстро износить диск, а на оперативную память это может пагубно сказаться?
Из вашего опыта, куда лучше кэшировать, в ОЗУ или ПЗУ, с учетом что ПЗУ это HDD?
Этот параметр может меняться от версии к версии и в целом пользователя волновать не должен. Для тех, кому это важно - есть возможность задать обьем вручную.
Занятый обьем будет увеличиваться по мере заполнения кеша.
Разумеется, с чего бы нам убирать ключи, которые появились задолго до опции в ГУИ?
Все когда-нибудь умирает. В целом же - нет, по сравнению с флешем в SSD ячейки DRAM постоянно обновляются (даже когда в них ничего полезного нет).
Из лично моего опыта это зависит от типа контента - live в ОЗУ, VOD - на диск, где “диск” это RAMdrive. Но я не смотрю 2К/4К медиа по 50-100 ГБ на файл.
