Nim хорош, но до того чтобы попробовать на нем какой-то продакшен все никак руки не дойдут. Кто-то пробовал на нем писать больше чем пару хелловорлдов? :)
Мне поменяли по гарантии, хотя я не сохранил с момента покупки вообще ничего, кроме самого девайса (даже зарядник, потому что купил сразу Quick Charge)
тут дело не в Type-C, потому что на Xperia Z / Xperia Tablet Z были microUSB без заглушки, которые тоже воды не боялись.
Хотя, по собственному опыту, если в воде на смартфон с таким разьемом наступить — то он может вобрать воду сквозь щели и сдохнуть :(
Но при более мягких ситуациях вроде «под душем» и «уронил в ванну» — нормально живет.
Там просто честный гамма-корректный ресэмплинг, где рассчитывается, какую площадь каких исходных пикселов накрывает результирующий пиксель (или субпиксель). Край прямоугольника либо резкий, либо взвешенный гауссиан.
Конечно, для увеличения оно выглядит как nearest neighour :)
При субпиксельном сглаживании соответственно рисуются честные прямоугольные пиксели с (примерной, к сожалению) развесовкой по яркостям.
Все пересчитывается в double, потом dither'ится. Характерная фича — если увеличить картинку (без субпиксельного сглаживания), а потом уменьшить — результат часто бит-в-бит совпадает.
ланцош, sinc и прочие делают вокруг высококонтрастных элементов круги (в случае белого на сером может получиться темно-серая кайма), они меня раздражают столь же сильно, сколь многих раздражает алиасинг :)
TLDR: идеального ресайза нет, смотрите, куда потом картинку использовать будете.
есть две основных, хм, «школы» ресайза картинок
а) давить частоты до полного отсутствия алиасинга, тогда у нас максимальная частота на квадратной решетке пикселей — 1/sqrt(2) линий на пиксель («линия толщиной не менее 1.4 пикселя»)
это нужно использовать, если ресайзятся, например, текстуры (которые будут потом сэмплиться еще раз). я полагаю, вы об этом.
б) добиваться максимального использования разрешающей способности (например, для шрифтов так ClearType работает), это означает что по горизонтали у нас получается 3 линий на пиксель («линия толщиной в 1 субпиксель»), и 1 линия по вертикали.
однако, картинку после этого нельзя ресайзить ВООБЩЕ, только показывать на RGB LCD мониторе 1:1, иначе будет уебище.
также уебище будет, если монитор не калиброван и гамма-кривые разных цветов расходятся, что чаще всего демонстрирует тот пример с кругами.
(ну и, строго говоря, я неправильно там сделал energy diffusion, но на ч/б картинке оно не влияет)
у меня на сайте dmnd.io есть переключатель между этими двумя вариантами, пробуйте :)
1) 2) ах вот оно что! я думал, там 100500 виртуалок с общего образа, чтобы экономить N*обьем образа на SSD, а если только одна, то это еще более удивительно…
3) собирайте. Сколько всего, кстати, виртуалок и какой общий обьем стореджа сейчас?
> занимаются ли этим контроллеры на современных SSD?
Да, но не все.
Плюс, бывает логика «тасовать когда ячейка начинает уже явно подыхать», «тасовать если долго туда ничего не писали» и много других вариантов.
> Берём SSD (у меня сейчас на 128Гб, поэтому для примера возьмём его)
Я очень сильно подозреваю, что в оценке экономии бюджета упущена экономия времени ;-)
Да, если SSD забивать до упора, будет тормозить. Учтите еще, что сама по себе NTFS плохо работает, если свободного места меньше 10-15% (начинают фрагментироваться битмапы, индексы и т.д.)
Сколько вам виртуалок надо разместить? Я очень сильно подозреваю, что докупить SSD на 1 Tb будет в итоге дешевле, чем изучать и оптимизировать гибридную конфигурацию.
Плюс, эмм, можно же купить Seagate Momentus, который гибрид HDD+SSD, и проверить, помогает ли оно. Кстати, там тоже SSD используется для часто используемых данных, а HDD — для редко используемых. Наводит на мысли =)
Учитывая, что Vista и выше, если считают, что диск HDD — группируют часто используемые фрагменты исполняемых файлов, а W8 и выше еще и дефрагментирует NTFS-структуры на лету с учетом оптимизации seek-ов, то в теории (и в принципе по моим опытам подтверждалось) имеет смысл, действительно, либо использовать ISR, либо размещать на SSD разностные диски, а базовый образ — на HDD (т.е. наоборот по сравнению с подходом, который пытался реализовать автор поста)
Я в итоге просто перешел на Intel'овские SSD и успокоился. По деньгам и времени на обслуживание выходит дешевле, чем городить гибридные системы или менять дешевые и глючные SSD-шки.
Насчет ресурса я написал ниже, дублировать коммент не буду.
Если прочитать соответствующий коммит, то на Windows они вызывают GetSystemTimeAsFileTime, а надо GetSystemTimePreciseAsFileTime.
Первый метод как раз обращается к старому таймеру (у которого точность от 1 мс до 16 мс), а второй — наносекундный.
Хотя, по собственному опыту, если в воде на смартфон с таким разьемом наступить — то он может вобрать воду сквозь щели и сдохнуть :(
Но при более мягких ситуациях вроде «под душем» и «уронил в ванну» — нормально живет.
Конечно, для увеличения оно выглядит как nearest neighour :)
При субпиксельном сглаживании соответственно рисуются честные прямоугольные пиксели с (примерной, к сожалению) развесовкой по яркостям.
Все пересчитывается в double, потом dither'ится. Характерная фича — если увеличить картинку (без субпиксельного сглаживания), а потом уменьшить — результат часто бит-в-бит совпадает.
TLDR: идеального ресайза нет, смотрите, куда потом картинку использовать будете.
есть две основных, хм, «школы» ресайза картинок
а) давить частоты до полного отсутствия алиасинга, тогда у нас максимальная частота на квадратной решетке пикселей — 1/sqrt(2) линий на пиксель («линия толщиной не менее 1.4 пикселя»)
это нужно использовать, если ресайзятся, например, текстуры (которые будут потом сэмплиться еще раз). я полагаю, вы об этом.
б) добиваться максимального использования разрешающей способности (например, для шрифтов так ClearType работает), это означает что по горизонтали у нас получается 3 линий на пиксель («линия толщиной в 1 субпиксель»), и 1 линия по вертикали.
однако, картинку после этого нельзя ресайзить ВООБЩЕ, только показывать на RGB LCD мониторе 1:1, иначе будет уебище.
также уебище будет, если монитор не калиброван и гамма-кривые разных цветов расходятся, что чаще всего демонстрирует тот пример с кругами.
(ну и, строго говоря, я неправильно там сделал energy diffusion, но на ч/б картинке оно не влияет)
у меня на сайте dmnd.io есть переключатель между этими двумя вариантами, пробуйте :)
а можно поподробнее, ну там, ссылку, или где их искать?
а то про Thumbs.db я знаю, про .DS_Store знаю, про OneNote тоже хочу узнать
Еще 520-тка жмет записываемые данные, т.е. записав 1 Гб ноликов реально потратится что-то вроде 50 Мб места. Насчет Evo не знаю.
3) собирайте. Сколько всего, кстати, виртуалок и какой общий обьем стореджа сейчас?
Да, но не все.
Плюс, бывает логика «тасовать когда ячейка начинает уже явно подыхать», «тасовать если долго туда ничего не писали» и много других вариантов.
> Берём SSD (у меня сейчас на 128Гб, поэтому для примера возьмём его)
Я очень сильно подозреваю, что в оценке экономии бюджета упущена экономия времени ;-)
Да, если SSD забивать до упора, будет тормозить. Учтите еще, что сама по себе NTFS плохо работает, если свободного места меньше 10-15% (начинают фрагментироваться битмапы, индексы и т.д.)
Сколько вам виртуалок надо разместить? Я очень сильно подозреваю, что докупить SSD на 1 Tb будет в итоге дешевле, чем изучать и оптимизировать гибридную конфигурацию.
Плюс, эмм, можно же купить Seagate Momentus, который гибрид HDD+SSD, и проверить, помогает ли оно. Кстати, там тоже SSD используется для часто используемых данных, а HDD — для редко используемых. Наводит на мысли =)
Я в итоге просто перешел на Intel'овские SSD и успокоился. По деньгам и времени на обслуживание выходит дешевле, чем городить гибридные системы или менять дешевые и глючные SSD-шки.
Насчет ресурса я написал ниже, дублировать коммент не буду.