Odissey Nemo

Раньше было на порядок больше дела, на два порядка меньше банков, рекламы, посредников, пробок, конкурентов, владельцев средств производства и инвесторов.
Совсем не было менеджеров. А были руководители (часто от бога), собаку съевшие на деле, которым занимались. Некоторых помним и сегодня, спусти 30 лет после их смерти. Придут ли сегодняшние программеры на могилку своего текущего тим-лида через 30 лет? ответ очевиден.
Отсюда и задачи стояли более интересные, разнообразные, ответственные. И ты мог заниматься ими десятки лет.
Пригождался любой человек, а не только юные гении, знающий все вопросы на собеседовании. Но не способные связать двух слов с товарищами или посоветовать что-то.
Вероятность получить в ответ на твой произвольный вопрос фразу: "Я занят, некогда мне с тобой" была исчезающе мала.
Больше времени люди проводили в обсуждениях совместных и мероприятиях вне работы (и отпуска проводили вместе). Мало, очень мало было личных проектов.
Работало много институтов. создающих свои машины, свои операционки, свои языки программирования.
И достигали реально многого. Уважали друг друга.
Уволить тебя, если ты не был откровенным тунеядцем. было невозможно.

В целом, работать было на порядок интереснее. И задачи стояли на порядок важнее и реальнее Как в программировании, так и в материальном производстве.

Основной смысл существования Java в том, что она работает везде приблизительно одинаково. Посему не следует использовать какой-либо софт, использующий нативные интерфейсы, за исключением собственно Java VM.

В этом случае решение - только Swing. На нём реально можно писать приложения, нисколько не уступающие нативным на Windows, скажем. И выглядят они неотличимо. По крайней мере, лучше Delphi ))) Чтобы вид Java-десктоп не отличался от натbвиного, достаточно одной строки кода. Тогда в разных системах приложение будет выглядеть слегка по разному (углы, цвета), но сохраняя основные геометрические соотношения между элементами GUI и взаимодействуя одинаково с файловой системой, БД, графикой!

Возможно, стоит поискать более высокоуровневые надстройки над Swing. Или самому сделать свою библиотеку, делающую нужные Вам вещи в 1-2 строки кода.

Есть и разнообразные компоненты, работающие со звуком, видео, 3D. Видел Doom-3 на Java через OpenGL.

Назови по русски (или на том языке, на котором мыслите), а потом переведите на английский. Так, чтобы было понятно тебе, в первую очередь. Иногда Гугль или Яндекс дают неплохие переводы, а иногда - отвратные. Для скорости можно использовать их, но обязательно и тщательно проверять смысл ими содеянного.

И старайтесь называть покороче, используя общепринятые сокращениями, на английском, конечно. Button == Btn, Rectangle == Rect, Point = Pnt, Control == Ctrl|Cntrl etc. RectangularButton == RectBtn, EscapeButton == EscBtn etc etc etc.

Числодробительный код на Java примерно в 2-3 раза медленнее, чем на С++ или, скажем, Delphi. Так кажется на собственной субъективном опыте. Т.к. на Java слишком много разных фич пристыкованы в байт-коде чисто механически.

Но писать программы со вполне удовлетворительным быстродействием вполне можно. Даже нумерологические. Скажем, полная обработка растров размерами 10000 на 10000 (бинаризация или другие матричные фильтры) средствами собственного кода (без нативных библиотек) вполне отрабатывает за секунды. Не утомляя пользователя. Но!Тут и встаёт вопрос о знании алгоритмов, вернее, какой где стоит применить.

Берётся любой алгоритм заливки одноцветного растрового полигона любым цветом, начиная с любой его точки заданного цвета. Они были ещё под ДОС заготовлены в любом растровой библиотеке (в том-же Борланде).

1. Ищется слева направо сверху вниз первая точка нужного цвета. Если не найдена - выход. Иначе на 2.
2. Точка запоминается на будущее. Начиная от найденной точки, заливается полигон, включающий её каким-либо рабочим цветом (алгоритмом заливки).
3. Определяются bounding box (экстенты) этого найденного полигона (top Y уже известен - как у первой точки) в растровой системе координат. Создаётся растр этого размера (или чуть расширенный для красивых границ). В него перегоняется найденный полигон.
4. Сохраняется найденный полигон в файл.
5. Из оригинального изображения устраняется найденный полигон. Скажем, методом той же заливки, но уже цветом отсутствия. Или вариацией операции XOR по цвету заливки.
6. Начиная с запомненной точки, ищется следующая точка нужного цвета.
7. Если найдена, на шаг 2.
8. Если не найдена, выход.

Не ясным пока остаётся поиск экстентов (Bounding box, BB). Самое простое - сканировать каждый раз весь исходный растр, что не комильфо. Или как-то модифицировать алгоритм заливки - с запоминанием экстентов. Что достаточно просто. И залил и экстенты получил за один раз.