adimetrius писал(а):
С другой стороны - фон Нейман продвигал мысль, что лучшее и простейшее описание сложной системы (напр. мозга) - это сама система. Так что тексты ББ - это самый лучший StackOverflow. Только не аннотированный.
с этим я совершенно не спорю. однако тут есть небольшой нюанс: документации или не должно быть вообще, или она должна быть как можно полнее. в первом случае я бы, понятно, не стал искать способ в документации, и полез рыть исходники. а так я предположил, что в документации — раз она есть — способ описан, и взял то, что нашёл. процедуры для root в документации упомянуты, но одной строкой: типа они есть. обычно так упоминают то, что использовать не рекомендуется. а `OpenBuffer()` описано довольно подробно. выбор, в принципе, был очевиден.
вообще, BBCB очень нужен документ типа: «обзор системы для испорченых другими средами, или как отучиться постоянно лазить в кишки и полюбить высокоуровневое программирование». у BBCB странности для «ненулевого новичка» начинаются уже с терминологии: «view -> frame -> root? wtf?! ой, ещё какие-то контексты упоминаются? а это что? упс, InstallFrame, оказывается, не перманентна, её можно и нужно вызывать в `Restore()`? ЧТОТУТПРОИСХОДИТААААА!!!1» это я к тому, что
переобучать несколько сложнее, и надо немного иначе, чем обучать с нуля. если я когда-нибудь найду лишние хотя бы часов пять в сутках — напишу, наверное. прежде всего потому, что такая книга нужна лично мне. ;-)
adimetrius писал(а):
Напрашивается: "пилите, шура, пилите" (с). Если надо - знач надо, пилите.
я получаю от этого некоторое извращённое удовольствие. ;-)
adimetrius писал(а):
"Этот - в книжку тычет пальчик", а подавляющий пользователь - давит мышку. Все эти аккорды - для профи. Имхо. Т.е. для нас, любимых, а значит - что может быть важнее )
ну, не скажите, не скажите. когда пользователь (по желанию, или по необходимости) переходит из разряда casual дальше — он тоже начинает ценить шорткаты. но в принципе, под пользователем я имел в виду того, кто в данный момент форму использует. мы же тоже часто просто пользователи. ;-)
adimetrius писал(а):
arisu писал(а):
а насчёт мусора — это, похоже, проблемы округлений из «универсальных» координат в пиксельные
Сомневаюсь, потому что в Вин не наблюдается.
хм. если вы сможете дать минимальный пример, где оно проявляется, и как этого добиться — я с удовольствием посмотрю, в чём причина. у меня пока что из мелкобагов рисовки только один, который я помню ещё по винде пятнадцать лет назад, поэтому и внимания не обращаю.
однако хочу заметить, что у винды и лина разный unit, и проблемы округления на винде могут не проявляться просто потому что повезло.
adimetrius писал(а):
arisu писал(а):
«пиксельные» порты должны работать не с челочисленными координатами пикселей, а хотя бы с 24.8 fixed point (а лучше и вовсе с плавающими)
А чем вам универсальные координаты - не числа с фиксированной запятой?
нененене, я не про это, я про те порты, которые в LinPorts и так далее. в смысле, самая нижняя реализация, её надо переделывать с пиксельной сетки на большее разрешение. мы постоянно путаемся в этом, надо какие-нибудь разные термины ввести, что ли.
я ни в коем случае не предлагаю трогать универсальные координаты: с ними всё в порядке. ну, кроме того, что я бы предпочёл их в плавающих, но это чистая вкусовщина.
adimetrius писал(а):
Отбирать OpenBuffer не надо, да и замучаешься; нормально как есть: написано не трогать руками, а решишь трогать - на твой страх и риск, может все "поехать".
а без этого не сделать правильное сглаживание: там в любом случае нужно сначала строить сцену, а потом растеризовать, и при этом надо ещё делать гамма-коррекцию, иначе будут сопли и неравномерность вместо иллюзии бо́льшего разрешения. вот
статья McSeem про необходимость гаммы.
adimetrius писал(а):
Про привязку к .dot. Если я правильно понимаю, привяжетесь к Frame.dot - и ваши виды не будут поддерживать масштабирование. Оно задается через Frame.unit.
да, dot вроде как (по документации) зависит от point, а не unit. но поскольку в стандартной поставке нет масштабирования по какому-нибудь Ctrl+Wheel, то… ;-)
adimetrius писал(а):
И тут возникает вилка: с одной стороны, чтобы масштабировалось, надо считать в универсалях и привязываться к .unit, а чтобы рамка толщиной третьмиллиметра со всех сторон была по 1 пикселю (а не 2 с одной, а остальные по 1, да еще и какая будет толстой - зависит от положения в контейнере) - надо учитывать .dot. (Меня на такую красоту не хватает - все эти расчеты и учеты программировать.)
да, это, конечно, решается качественной библиотекой aa rendering. но у BBCB такой всё равно в поставке нет. ;-)
это у нас получается эхо конфликта «рисование шрифтов m$-style vs рисование шрифтов apple-style». m$ делает неправильно, но за счёт рихтования по пиксельной сетке выглядит (выглядело во время оно) лучше, чем «размазня» у apple.
я вам признаюсь, что любую размазню люто ненавижу, потому что у меня очень, очень плохое зрение. и если я вижу «нечёткие пикселы», то я автоматически начинаю напрягать глаза, потому что мне кажется, что это у меня зрение поехало, а не программа пиксел размазала. поэтому я совершенно автоматически стараюсь всё, что делаю, прибивать к пиксельной сетке.