LINUX.ORG.RU

[Ненависть] Метод paint

 


0

0

Вот сижу и думаю: зачем в SWING тупой метод paint? Если тебе где-то что-то нужно нарисовать, ты не можешь просто взять, и вызвать функцию, ты обязан отнаследоваться, создав свой компонент, переопределить там метод paint, и еще придумать массу извратов, чтобы там что-то рисовалось. Притом если тебе нужно из программы нарисовать что-то непредсказуемое на данном компоненте, то ты не можешь этого сделать, т.к. надо переписывать метод paint (в рантайме никак). Я уж не говорю про тормоза, возникающие от того, что при каждой перерисовке картинка заново рендерится: рисуется фон, фигуры, картинки...

Неужели нельзя было просто засунуть во все компоненты SWING, на которых можно рисовать, матрицу пикселей? Чтобы на ней просто рисовать, а изменения сохраняются и автоматически отрисовываются когда нужно?

Мало того, в SWING нельзя взять цвет одного пикселя или нарисовать один пиксель (это относится и к компонентам, и даже к картинкам)!! Для того, чтобы сделать эти элементарные операции нужно много много извращений, порождения новых объектов и т.д..

Вспоминаю старый добрый C++Builder, и грустно становится.

★★

> Неужели нельзя было просто засунуть во все компоненты SWING, на которых можно рисовать, матрицу пикселей? Чтобы на ней просто рисовать, а изменения сохраняются и автоматически отрисовываются когда нужно?

Класс, реализующий такой вариант paint, пишется в десять строк. Только нужна такая гадость очень редко.

А ты просто не умеешь писать на Java и не понимаешь ООП.

anonymous
()
Ответ на: комментарий от anonymous

> Класс, реализующий такой вариант paint, пишется в десять строк. Только нужна такая гадость очень редко.
> А ты просто не умеешь писать на Java и не понимаешь ООП


С одной стороны делать подобную гадость нужно действительно нечасто.
С другой стороны - вот он, ООП-маразм во всей красе, чуть что - сразу наследовать, а ведь наследование - это весьма негибкая штука.

ShprotX
()
Ответ на: комментарий от anonymous

>Класс, реализующий такой вариант paint, пишется в десять строк

А какого **я тогда я должен делать за мегаэнтерпрайзный инструмент самые банальные вещи? Напиши это, напиши то, пропатч весь SWING чтобы он нормально рисовал компоненты, пропатч класс картинки, чтобы она пиксели понимала, и т.д и т.д.. Была бы моя воля, выбрал бы даже Си. На нем и то быстрее можно писать программы, потому что хоть синтаксис не сахар, но дописывать библиотеки не нужно.

>А ты просто не умеешь писать на Java и не понимаешь ООП.

-- Не насилуйте меня, мне больно!

-- Не больно, мальчик. Ты просто не понимаешь принципов анального секса.

xTERM ★★
() автор топика

>Мало того, в SWING нельзя взять цвет одного пикселя или нарисовать один пиксель (это относится и к компонентам, и даже к картинкам)!! Для того, чтобы сделать эти элементарные операции нужно много много извращений, порождения новых объектов и т.д..

Операции "закрасить пиксель" в программисткой практике не существует. Есть только битблиттинг и векторные примитивы.

Absurd ★★★
()

>Вспоминаю старый добрый C++Builder, и грустно становится.

А вы, батенька, извращенец, как я погляжу, ущербнее билдера и vcl трудно что либо найти.

wfrr ★★☆
()

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

Матрицу пикселей говроишь, то есть в компонент нужно еще что-то встроить, что отлавливало бы изменения в этой самой матрице. Или тебе самому пришлось бы вызывать некий метод... Как бы не очень. Во-вторых, Graphics ты откуда возьмешь? Как бы еще к этому барахлу и get* добавится. К тому же твоя матрица - это очень негибкое решение. К тому же с какой стати, компонент должен кому-то отдавать матрицу пикселей? А если ты наследуешь, то ты - детеныш ненаглядный, почему бы тебе и не разрешить порисовать. Пойми ООП.

Ian ★★
()
Ответ на: комментарий от redgremlin

Я пробовал, но только маленькие проектики. Отдам голос за Swing =)

Ian ★★
()

Ты, видимо, не очень понимаешь Graphics 2D...

Что касается замены пикселя, то кто тебе сказал, что Graphics указывает обязательно на устройство монитора?!! Там может оказаться и принтер, и запись графики в файл, и вообще, все что-угодно, где нет операции замены пикселя.

Кстати, твои стоны про большое количество кода как-то неуместны. По-моему там все довольно компактно получается.

В третьих, двухмерная графика не так проста как может показаться. Итак, очень многое упрощено. Тем более, в явовской Graphics 2D. Может быть, эта реализация не такая быстрая, но с точки зрения архитектуры все выглядит очень даже круто. К примеру, можно создать свою собственную реализацию Graphics.

В качестве сравнения. В GDI+ та же фигня с наследованием. Хотя можно отловить событие Paint, но на мой взгляд такое решение будет ущербным.

dave ★★★★★
()
Ответ на: комментарий от anonymous

>А что с winapi не то? Примитивизм жеж...

Полное отсутствие концепта во всем, начиная от стиля возвращения строк заранее ниеизвестного размера.

Absurd ★★★
()
Ответ на: Re^2: [Ненависть] Метод paint от gaa

>> ущербнее билдера и vcl трудно что либо найти.

>mfc

Он во-первых дает "родной" врешний вид приложениям в отличие от vcl где кондовая дельфятина режет глаза, а во вторых к mfc идет куча хороших компонент типа ObjectiveGrid.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Полное отсутствие концепта во всем, начиная от стиля возвращения строк заранее ниеизвестного размера

Ну дык для сишных API по-моему это и есть норма - возвращать данные заранее неизвестного размера чережжо.

ShprotX
()
Ответ на: комментарий от ShprotX

>> Полное отсутствие концепта во всем, начиная от стиля возвращения строк заранее ниеизвестного размера

>Ну дык для сишных API по-моему это и есть норма - возвращать данные заранее неизвестного размера чережжо.

Что мешало внедрить единое соглашение? Быдло-COM же внедрили.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Он во-первых дает "родной" врешний вид приложениям в отличие от vcl где кондовая дельфятина режет глаза, а во вторых к mfc идет куча хороших компонент типа ObjectiveGrid

Я чего-то недопонимаю: в чем проявляется неродимость VCL? А во-вторых, к VCL тоже много чего идет.

ShprotX
()
Ответ на: комментарий от Absurd

> Что мешало внедрить единое соглашение? Быдло-COM же внедрили.

Поправьте меня если не прав, но WinAPI был разработан до COM. К тому же, прошу обратить внимание на тот же POSIX, который в этом плане не уступает WinAPI.

ShprotX
()
Ответ на: комментарий от ShprotX

>> Что мешало внедрить единое соглашение? Быдло-COM же внедрили.

>Поправьте меня если не прав, но WinAPI был разработан до COM.

Речь идет не о хронологии, а о принципиальной возможности нормализовать интерфейс. BTW, Есть мнение что OS/2 API на голову выше WinAPI т.к MS спешил родить нечто раньше IBM, а IBM хотела родить качественный продукт, т.е была война между инженерной культурой и маркетингом в которой маркетинг победил.

>К тому же, прошу обратить внимание на тот же POSIX, который в этом плане не уступает WinAPI.

Какая часть POSIX лично вас не устраивает? Сравните количество параметров у CreateFileW() и creat().

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Речь идет не о хронологии, а о принципиальной возможности нормализовать интерфейс

Согласен. А внедрить единое соглашение мешала страсть к баблу.

> Какая часть POSIX лично вас не устраивает? Сравните количество параметров у CreateFileW() и creat()


Меня не устраивает как минимум организация передачи данных переменного размера. Особо трэшевая вещь - строки с нулем на конце. Я конечно понимаю, что 3 (или 7) байта - это недопустимая жертва, но все же.
Да, параметры у функций в WinAPI весьма веселые, особенно в районе авторизации, где их кол-во стабильно 10+.
Да, WinAPI хуже, чем POSIX, но и POSIX не сахар.

ShprotX
()
Ответ на: комментарий от Absurd

>Он во-первых дает "родной" врешний вид приложениям в отличие от vcl где кондовая дельфятина режет глаза

ты исходники vcl видел? там снизу методы winapi и именно winapi задает внешний вид компонент

>во вторых к mfc идет куча хороших компонент типа ObjectiveGrid.


к vcl тоже идет куча хороших компонент.

а что такое ObjectiveGrid? TDrawGrid чтоле?

generatorglukoff ★★
()
Ответ на: комментарий от Absurd

>Полное отсутствие концепта во всем, начиная от стиля возвращения строк заранее ниеизвестного размера.

это бредовый аргумент. основные проблемы:
1. попытка свести гуся, рака и щуку в одном вызове/структуре. в результате имеем длинные мантры вызовов и потерю понимания происходящего
2. наслоение функционала, как выходящее из первого: вместо того, чтобы добавлять по одному функционал имеем Ex функции.
3. WINAPI ЯВНО ПИСАЛА БЛОНДИНКА

generatorglukoff ★★
()
Ответ на: комментарий от generatorglukoff

>>Он во-первых дает "родной" врешний вид приложениям в отличие от vcl где кондовая дельфятина режет глаза

>ты исходники vcl видел? там снизу методы winapi и именно winapi задает внешний вид компонент

Даже Java SWING в конце концов вызывает WINAPI чтобы нарисовать результат. Вопрос в том *как* она это делает. Наиболее честно - передавать ресурс диалога и указатель на оконную функцию API-вызову DialogBox(), тогда диалог будет выглядеть нативно. Можно сделать свой менеджер компоновки и свой формат диалоговых ресурсов как в VCL. А можно просто брать у Винды прямоугольники на экране и в них все рисовать руками.

>а что такое ObjectiveGrid? TDrawGrid чтоле?

http://www.roguewave.com/products/stingray.php

Absurd ★★★
()
Ответ на: комментарий от ShprotX

>Да, WinAPI хуже, чем POSIX, но и POSIX не сахар.

Ну, не скажите батенька. В POSIX довольно всё логично. Слегка стариной отдает, но в целях обратной поддержки - разумно. А настоящая проблема не с POSIX, а с тем как его трактуют производители ПО. Если надо написать нечто переносимое задолбаешься константы выверять (хотя не смертельно, но утомляет).

shty ★★★★★
()
Ответ на: комментарий от Absurd

> Наиболее честно - передавать ресурс диалога и указатель на оконную функцию API-вызову DialogBox(), тогда диалог будет выглядеть нативно. Можно сделать свой менеджер компоновки и свой формат диалоговых ресурсов как в VCL

VCL использует оба варианта.

> http://www.roguewave.com/products/stingray.php


Во-во, началось мерянье табличками. Раз уж на то пошло, для VCL есть, например, EhLib: http://www.ehlib.com/ehlibdemo_rar.exe

ShprotX
()
Ответ на: комментарий от Ian

>> Даже Java SWING в конце концов вызывает WINAPI чтобы нарисовать результат.

>4.2.

А что, он напрямую в видеопамять пишет? Или ядерный драйвер для джавовской графики в винду ставится?

Absurd ★★★
()
Ответ на: комментарий от Absurd

Swing использует для рендеринга компонентов Java2D + возможности "тяжелого" Container, для того что бы "встроиться" в системное окружение(например для обработки ввода с клавиатуры).

В свою очередь Java2D возможно и использует WinAPI, но она так же может использовать OpenGL.

Если я ошибаюсь, поправьте.

Ian ★★
()
Ответ на: комментарий от Ian

Дабы не быть голословным, предлагаю вам попробовать запустить Java2Demo.jar из комплекта поставки JDK версии 1.5 и старше вот так:

java -Dsun.java2d.opengl=True -jar Java2Demo.jar

Ian ★★
()
Ответ на: комментарий от anonymous

> Не знаю, у меня хоть с True, хоть с False -- ~33fps. Debian testing, java 1.6.*, дрова на nvidia стоят.

Ну так уменьши "Anim Delay" до 1 ms :)

kamre ★★★
()
Ответ на: комментарий от dave

> В третьих, двухмерная графика не так проста как может показаться. Итак, очень многое упрощено. Тем более, в явовской Graphics 2D. Может быть, эта реализация не такая быстрая, но с точки зрения архитектуры все выглядит очень даже круто.

Недавно пытался сравнить 2D графику в Qt и Java2D: http://trac-hg.assembla.com/jgears/wiki/ResultsHome

В принципе не так уж и сильно отстает Java2D от Qt. Существенная разница только с Qt OpenGL pipeline, т.к. сглаживание Qt полностью за счет видеокарты делает (по качеству хуже получается, зато быстрее).

kamre ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.