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

MS>2. Приделать механизм автоматического восстановления состояния. Типа BeginSessoin() добавляет некий entry в стек, EndSession() восстанавливает все изменившиеся после BeginSessoin() параметры. Эти вызовы могут быть вложенными. Для автоматизации вызовов делается простейший scope guard (в C# — using) — очень похоже на SVG или XAML.

Чем это отличается от Graphics.BeginContainer/EndContainer?

MS>Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.

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

MS>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.

А что ты скажешь о System.Windows.Media?

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

AVK>Чем это отличается от Graphics.BeginContainer/EndContainer?

Так он же только аффинный трансформер сохраняет. Кстати, почему они назвали его "Container"? Почему не "Transformer"?

MS>>Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.

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

Не совсем. Растровые конвейеры — безусловно должны работать в HW (это то, что GPU умеет делать хорошо — молотить цвета в параллель), но возможности вертексных шейдеров сильно ограничены (фактически они сильно связаны с растровыми — посчитать нормаль, цвет в вершине и т.д.). Но при помощи их все равно невозможно, например, вычислить stroke. И невозможно триангулировать полигон. То есть, все равно это надо считать на CPU. А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.

MS>>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.

AVK>А что ты скажешь о System.Windows.Media?

Да то же самое — все намешано в одну кучу. Догадались выделить в отдельный класс геометрию, да и то криво. Например, PathGeometry звучит как масло-масляное — Path это собственно и есть Geometry. Или FillRule — это фундаментальное свойство растеризатора, а не геометрии. Можно, например, попросить растеризатор нарисовать два или больше путей как единое целое? — это тривиальная операция и очень полезная. Но если можно, то у разных путей могут быть разные FillRule, у одного NonZero, а у другого — EvenOdd. И что делать растеризатору? — он не может работать одновременно с двумя. Это я к тому, что даже при беглом взгляде обнаруживаются внутренние противоречия.

Ну почему надо упираться рогом в свои ущербные и противоречивые концепции, а не посмотреть, например, на тот же OpenVG?

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

MS>>Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.

AG>Это интересно. Но тут уже вопрос: а зачем сообществу программистов растеризация Flash? Если говорить о популярности библиотеки, то IMHO на ее популярность это никак не повлияет.

Ну это лично мне кажется более персперктивным. Что же касается популярности, то я не уверен, что оно мне надо, прежде всего потому, что это очень большая нагрузка, с которой я могу чисто физически не справиться. Могу делегировать свои полномочия на разработку обертки в виде GDI+ кому-нибудь другому. Могу оказывать консультации и т.д.

AG>Странно... мне совсем не показалось, что GDI+ ограничен в интерфейсе. Довольно-таки простая в использовании либа,

Ограничен. Где, например, встроенные перспективные преобразования? Да там все тупо сделано. Фишки нет.

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

AVK>>Чем это отличается от Graphics.BeginContainer/EndContainer?

MS>Так он же только аффинный трансформер сохраняет.

А там есть что еще сохранять?

MS> Кстати, почему они назвали его "Container"? Почему не "Transformer"?

Наверное все же он сохраняет что то еще . Например Clipping.

MS>Не совсем. Растровые конвейеры — безусловно должны работать в HW (это то, что GPU умеет делать хорошо — молотить цвета в параллель), но возможности вертексных шейдеров сильно ограничены (фактически они сильно связаны с растровыми — посчитать нормаль, цвет в вершине и т.д.). Но при помощи их все равно невозможно, например, вычислить stroke. И невозможно триангулировать полигон. То есть, все равно это надо считать на CPU.

Это не страшно. Как показывает практика с векторными операциями CPU справляется, благо их обычно не так много. Главное растровые вещи акселерировать.

MS> А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.

Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.

MS>Ну почему надо упираться рогом в свои ущербные и противоречивые концепции, а не посмотреть, например, на тот же OpenVG?

Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.

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

MS>>Так он же только аффинный трансформер сохраняет.
AVK>А там есть что еще сохранять?
MS>> Кстати, почему они назвали его "Container"? Почему не "Transformer"?

AVK>Наверное все же он сохраняет что то еще . Например Clipping.

Ну вот. Значит, парадигма stateless Graphics является утопией. Кстати, такие вещи, как Clipper, Transformer, Stroker являются по сути равноправными элементами конвейера. На входе точки и на выходе точки. А вот в какой последовательности их использовать — этим надо уметь управлять. Например, может быть так:
Path->Transformer->Clipper->Stroker->Transformer2->Clipper2

MS>> А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.

AVK>Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.

Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.



Вот скажи пожалуйста, при scale(0.5, 1), как должна выглядеть толстая линия в 99% случаев? Как на нижнем рисунке или как на предпоследнем? Имей в виду, что любое предпочтение я тут же аргументированно оспорю. Потому что нет его, этого предпочтения — в одних ситуациях требуется одно поведение, в других — другое.

AVK>Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.

Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии. Кружочки в Visio рисовать можно, но чуть более heavy duty — и кирдык.

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

MS>Ну вот. Значит, парадигма stateless Graphics является утопией.

Там вобще то чистый stateless и не заявлен. А отказ от выбора ручки или кисти скорее всего связан с большим количеством ошибок, когда забывают переключить кисть, и с тем, что этот выбор стимулирует группировать отрисовку не по семантике, а по стилю.

MS> Кстати, такие вещи, как Clipper, Transformer, Stroker являются по сути равноправными элементами конвейера. На входе точки и на выходе точки. А вот в какой последовательности их использовать — этим надо уметь управлять. Например, может быть так:
Path->>Transformer->Clipper->Stroker->Transformer2->Clipper2

Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?

AVK>>Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.

MS>Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.

Попробуй привести простейшие примеры на псевдокоде.

MS>Вот скажи пожалуйста, при scale(0.5, 1), как должна выглядеть толстая линия в 99% случаев? Как на нижнем рисунке или как на предпоследнем? Имей в виду, что любое предпочтение я тут же аргументированно оспорю. Потому что нет его, этого предпочтения — в одних ситуациях требуется одно поведение, в других — другое.

Понимаешь — в большинстве случаев мне по барабану.

AVK>>Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.

MS>Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии.

А он для этого и не делался. Нужно просто понять для чего он создавался — только для того чтобы заменить GDI, который, прежде всего, предназначен для отрисовки пользовательского интерфейса. И задача эта не менее серьезная, нежели картография, просто акценты в ней другие.

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

AVK>Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?

Я хочу сказать, что эта последовательность жестко, раз и навсегда приколочена гвоздями внутри.

MS>>Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.

AVK>Попробуй привести простейшие примеры на псевдокоде.

Типа так — типовой конвейер для рисования линий на основе полигонов, самый примитив:

Path path = new Path();
CurveFlattener curve = new CurveFlattener(path);         // Дробит кривые на прямые отрезки
Stroker stroker = new Stroker(curve);                    // Вычисляет эквидистанту к ломаной
AffineTransformer trans = new AffineTransformer(stroker);// Поворот, маштабирование, etc
PolygonClipper clipper = new PolygonClipper(trans);      // Отсечение полигона по прямоугольнику

// Далее мы выполняем:
path.MoveTo(. . .);
path.LineTo(. . .);
path.CurveTo(. . .);
. . .
// Геометрические параметры элементов конвейера
stroker.width(3.5);
stroker.LineJoin(Round);
trans.Rotate(35.0);
clipper.ClipBox(0,0,100,100);
. . .
// Рисуем
graphics.Render(clipper);

Это на самом низком уровне и только одна из возможных форм. Может быть что-то типа graphics.AddPipelineElement(new Stroker()) вместо того, чтобы "коннектить" их вручную). И понятно, что типовые конвейеры должны быть заранее определены, чтобы не возиться каждый раз с их созданием. Но надо обязательнео иметь возможность создавать конвейеры самому. Более того — создавать элементы конвейера самому. Как, например, мне "завернуть" декартово пространство в полярное? — чтобы на входе я пользовался обычными координатами, а рисовалось в виде круговой диаграммы (это не прихоть, это реальная задача для схематического отображения кольцевых ДНК). Такая схема создает принципиальную возможность расширения функциональности, в отличие от набора тривиальных ad-hoc решений. Можешь поверить на слово, в любой более-менее сложной задаче, где надо что-то рисовать, очень быстро упираешься в ограничения. И работа превращается в постоянный поиск обходных путей — меня от этого тошнит.

AVK>Понимаешь — в большинстве случаев мне по барабану.

Вот именно. И подавляющему большинству — тоже по барабану. Это и есть политика преднамеренной профанации. Зачем вообще изучать типографику, знать, какие бывают линии и что делают те или иные преобразования? Зачем вообще знать, что 2*2=4? — можно взять калькулятор и посчитать. Я конечно понимаю мотивы такой политики, но мне она не по душе.

MS>>Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии.

AVK>А он для этого и не делался. Нужно просто понять для чего он создавался — только для того чтобы заменить GDI, который, прежде всего, предназначен для отрисовки пользовательского интерфейса. И задача эта не менее серьезная, нежели картография, просто акценты в ней другие.

Неправда. Называется — GDI, Graphics Device Interface, то есть, штука, претендующая на универсальность. А потом выясняется, что ей только UI и можно рисовать. Ну что за дела?

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

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

AVK>>Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?

MS>Я хочу сказать, что эта последовательность жестко, раз и навсегда приколочена гвоздями внутри.

Погоди. Я могу последовательно вызывать методы Graphics, меняющие его состояние и от этой последовательности, по идее, должен зависеть результат.

AVK>>Попробуй привести простейшие примеры на псевдокоде.

MS>Типа так — типовой конвейер для рисования линий на основе полигонов, самый примитив:

MS>

MS>Path path = new Path();
MS>CurveFlattener curve = new CurveFlattener(path);         // Дробит кривые на прямые отрезки
MS>Stroker stroker = new Stroker(curve);                    // Вычисляет эквидистанту к ломаной
MS>AffineTransformer trans = new AffineTransformer(stroker);// Поворот, маштабирование, etc
MS>PolygonClipper clipper = new PolygonClipper(trans);      // Отсечение полигона по прямоугольнику

MS>// Далее мы выполняем:
MS>path.MoveTo(. . .);
MS>path.LineTo(. . .);
MS>path.CurveTo(. . .);
MS>. . .
MS>// Геометрические параметры элементов конвейера
MS>stroker.width(3.5);
MS>stroker.LineJoin(Round);
MS>trans.Rotate(35.0);
MS>clipper.ClipBox(0,0,100,100);
MS>. . .
MS>// Рисуем
MS>graphics.Render(clipper);
MS>

Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.

MS>Вот именно. И подавляющему большинству — тоже по барабану. Это и есть политика преднамеренной профанации.

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

MS> Зачем вообще изучать типографику, знать, какие бывают линии и что делают те или иные преобразования? Зачем вообще знать, что 2*2=4? — можно взять калькулятор и посчитать. Я конечно понимаю мотивы такой политики, но мне она не по душе.

Все это здорово, но надо помнить, что GDI+ не для твоей души создавался.

MS>Неправда. Называется — GDI, Graphics Device Interface, то есть, штука, претендующая на универсальность.

По факту он используется для GUI и иногда для вывода на принтер. Все.

MS>Но это есть хорошо! Ибо пока у MS-архитекторов отключен думатель и включен круиз-контроль, у меня будет незанудная и высокооплачиваемая работа.

МС никогда на этот рынок и не претендовал.

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

AVK>Погоди. Я могу последовательно вызывать методы Graphics, меняющие его состояние и от этой последовательности, по идее, должен зависеть результат.

Это все очень ограниченно, так сказать, капля в море. Я подозреваю, что под "методы Graphics, меняющие его состояние" ты подразумеваешь аффинный трансформер внутри него. Я уже приводил пример с широкой линией. В одних случаях надо так, в других — сяк. В GDI+ нет возможности этим управлять. А то что тебе "пофиг", не является сколько-нибудь значимым аргументом.

AVK>Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.

Подобные утверждения принято обосновывать. Ну и потом, удобство/неудобство — это понятия субъективные, в то время как наличие той или иной возможности — это фундаментальное свойство. Я уже приводил пример с "выпучиванием" a-la MacOS-X http://antigrain.com/stuff/sketcher.zip
Я просто подменяю конвейер (точнее, модифинцирую его), а сами кнопки (или что там еще рисуется) знать не знают, насколько там прямо или криво будет нарисовано. Вот весь код трансформера (на C++, но не суть):

        void transform(double* x, double* y) const
        {
            double dx = *x - m_xc;
            double dy = *y - m_yc;
            double r = sqrt(dx * dx + dy * dy);
            double rm = m_radius / m_magn;
            if(r < rm)
            {
                *x = m_xc + dx * m_magn;
                *y = m_yc + dy * m_magn;
                return;
            }
            double m = (r + rm * (m_magn - 1.0)) / r;
            *x = m_xc + dx * m;
            *y = m_yc + dy * m;
        }

Тривиально! Но поди встрой его в конвейер GDI+ — и съешь конфетку обломиську. Надо приделывать что-то снаружи и модифицировать сам код, который рисует контролы (во всех контролах!). И ты при этом намекаешь на удобство GDI+ для рисования UI? В общем, душит-смех-низачот.

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

Ну чего тогда споришь?
Это так, шутка. Спорь конечно же — мне приятно с тобой беседовать.

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

MS>Это все очень ограниченно, так сказать, капля в море. Я подозреваю, что под "методы Graphics, меняющие его состояние" ты подразумеваешь аффинный трансформер внутри него. Я уже приводил пример с широкой линией. В одних случаях надо так, в других — сяк. В GDI+ нет возможности этим управлять. А то что тебе "пофиг", не является сколько-нибудь значимым аргументом.

То есть ты считаешь, что в любых ситуациях единственно верное решение — максимально навороченное?

AVK>>Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.

MS>Подобные утверждения принято обосновывать.

Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.

MS> Ну и потом, удобство/неудобство — это понятия субъективные, в то время как наличие той или иной возможности — это фундаментальное свойство. Я уже приводил пример с "выпучиванием" a-la MacOS-X http://antigrain.com/stuff/sketcher.zip

А я тебе уже ответил на это — лишние возможности тоже далеко не всегда благо.

MS>Тривиально! Но поди встрой его в конвейер GDI+ — и съешь конфетку обломиську. Надо приделывать что-то снаружи и модифицировать сам код, который рисует контролы (во всех контролах!).

Все очень просто — не нужно контролам никаких трансформеров, а тем паче тонкости по настройке конвеера трансформера.

MS>В общем, душит-смех-низачот.

Поглядывай на правила.

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

MS>Ну чего тогда споришь?

Я просто намекаю на то, что критерии для оценки GDI+ выбраны несколько не те. Это примерно как оценивать Камаз на предмет наличия в нем CD-changer.

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

AVK>То есть ты считаешь, что в любых ситуациях единственно верное решение — максимально навороченное?

Ты так ничего и не понял. Тот псевдо-код не нужно повторять каждый раз, когда тебе надо нарисовать линию. Это свсего лишь некий setup, конфигуратор. Какая такая "навороченость"? Вот в GDI+ — уж действительно, наворотили так наворотили. А толку — чуть.

AVK>Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.

Сюрприз — будет примерно то же самое, что и на GDI+. Разница же в другом. Еще раз и медленно. При моем подходе я могу так сконфигурировать конвейеры, чтобы контролы рисовались совершенно по другому. При этом их код не будет затронут. С GDI+ такой возможности нет в принципе — там внутри все приколочено шиферными гвоздями.

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

ПК>>"Имя, сестра, имя!" Какой оно температуры и цвета?

VD>Он цвета лазурного восхода и тепературы парного молока.

...только зелёного!!!

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

AVK>>Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.

MS>Сюрприз — будет примерно то же самое, что и на GDI+.

Не будет. Ты же сам тут распинался по поводу stateful/stateless. Так вот — по моей практике удобнее указывать кисти по месту, а не переключать их в контексте.

MS> Разница же в другом. Еще раз и медленно. При моем подходе я могу так сконфигурировать конвейеры, чтобы контролы рисовались совершенно по другому. При этом их код не будет затронут. С GDI+ такой возможности нет в принципе — там внутри все приколочено шиферными гвоздями.

Еще раз и медленно. В типовом сценарии применения GDI+ эти возможности и не нужны.

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

AVK>Не будет. Ты же сам тут распинался по поводу stateful/stateless. Так вот — по моей практике удобнее указывать кисти по месту, а не переключать их в контексте.
Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер для этого дела и раблотать както так

GdiPlusLikeConveyor c = new GdiPlusLikeConveyor(graphics);
GdiPlusLikePen pen1 = new GdiPlusLikePen(color1, brush1);
GdiPlusLikePen pen2 = new GdiPlusLikePen(color2, brush2);
c.Line(. . ., pen2);
c.Circle(. . ., pen1);
c.SetPen(pen1);
c.MoveTo(. . .);
c.LineTo(. . .);
c.CurveTo(. . .);
c.SetPen(pen2);
c.MoveTo(. . .);
c.LineTo(. . .);
c.CurveTo(. . .);
c.Flush();

И что это сложнее GDI+?
За то если таки понадобится сделать что-то болие навороченое то...

AVK>Еще раз и медленно. В типовом сценарии применения GDI+ эти возможности и не нужны.
Но они и не мешают.

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

WH>Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер

Ты еще не забыл, что мы обсуждаем удобный API. А удобный API хелперов не требует.

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

WH>>Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер
AVK>Ты еще не забыл, что мы обсуждаем удобный API. А удобный API хелперов не требует.
Меня в принципе и предложеный API вполне устраивает.

Это все, конечно, очень благородно, но...

Давайте попробуем себе представить деревню во время посевной. Ежели я в проведении аналогий где-то сильно облажаюсь — просьба сильно ногами не пинать, я парень городской. И вообще — не воспринимайте слишком серьезно.

Значица — посевная. Народ — пашет по-черному. План по валу, вал по плану, все дела.
И посредине всего этого — деятель, а-а-аккура-а-аатненько так сажающий зернышко за зернышком. Перед тем как
посадить — каждому поет колыбельную. Угол и глубину посадки без отвеса и штангенциркуля мерить даже и не берется. Собственно, процентов 30 времени он не сеет, а совершенствует инструментарий.

На каждое зернышко капает из пипетки особым раствором — по его данным, урожайность от него аж на 7.3% выше, чем при использовании стандартных удобрений. Ежели угол посадки его не удовлетворяет, он выкапывает зернышко и сажает его повторно. Вообще, в определении идеальных угла и глубины посадки он — лучший в районе. Есть даже подозрение, что на международном состязании по точечному засеву он вошел бы в десятку. Жаль, что таких соревнований нигде не проводят.

На замечания окружающих, что занимается он х@@@й и другие за то же время засевают в 100 раз больше гордо отвечает, что вышеупомянутым недостойным делом занимаются как раз все остальные. А именно — тупой и монотонной работой, которая ему неинтерестна. Он — Творец и Мастер. На его участке урожай на 30% выше, чем у всех остальных — и это далеко не предел. О позапрошлом сезоне, когда семейство долгоносиков сожрало весь его урожай (4 квадратных метра) он предпочитает не вспоминать. Не ошибается тот, кто ничего не делает.

В кругу друзей — он признанный Гуру и Гений. Все понимают — во-первых, он себя полностью реализовал и уже потому успешен, а во-вторых — будущее за его технологиями — когда он найдет верную методику точечной засадки, все комбайны будут автоматически ее воспроизводить и всем будет счастье. Тот факт, что у гуру незаконченное среднее образование, слово "агроном" он пишет с ошибками и временами путает химию с алхимией друзей не смущает.

Университет, вкладывающий миллиард долларов ежегодно в разработку удобрений и комбайнов нового поколения их тоже не смущает — куда этим криволапым мелко-очкастым до нашего Василия Пупкина! Всех порвем, не впервой!

И что любопытно — никаких причин жалеть Васю Пупкина нет и быть не может. Он вполне себе счастливый человек. А вот кого можно и нужно пожалеть, так это директора местного совхоза "Назад в коммунизм". За что ему такое счастье?

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

VD>Он цвета лазурного восхода и тепературы парного молока. В общем, ничего интересного. Можешь не смотреть.

Батенька, Вам надо срочно обратиться к психиатору. Я абсолютно серьезно говорю. Нельзя затягивать. Такие вещи хорошо не кончаются.

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

M>Значица — посевная. Народ — пашет по-черному. План по валу, вал по плану, все дела.
M>И посредине всего этого — деятель, а-а-аккура-а-аатненько так сажающий зернышко за зернышком. Перед тем как
M>посадить — каждому поет колыбельную. Угол и глубину посадки без отвеса и штангенциркуля мерить даже и не берется. Собственно, процентов 30 времени он не сеет, а совершенствует инструментарий.

M>На каждое зернышко капает из пипетки особым раствором — по его данным, урожайность от него аж на 7.3% выше, чем при использовании стандартных удобрений. Ежели угол посадки его не удовлетворяет, он выкапывает зернышко и сажает его повторно. Вообще, в определении идеальных угла и глубины посадки он — лучший в районе. Есть даже подозрение, что на международном состязании по точечному засеву он вошел бы в десятку. Жаль, что таких соревнований нигде не проводят.

Фигня. Неправильное сравнение. Некошерное. Правильно было бы так:

А рядом с колхозом есть эспериментальное хозяйство, где некто McSeem2 выращивает новые сорта. Вот туды они перед посевной и бегут. За посевным материалом. И потом ходют консультироваться — как лучше им удобрять, когда сажать, какой цикл должен быть, чтобы значить были максимальные урожаи. Понял?

>Понял?
Я вообще понятливый. Хрен они туда бегут. И хрен они с ним консультируются. Есть в мире хозяйства покрупнее и авторитеты гораздо солиднее. А деятель этот никому не нужен.
Понял?

P.S. Лично с автором незнаком, о его заслугах ничего не знаю и лично против него ровным счетом ничего не имею. Говорю и подходе в целом.