Line(x1,y1,x2,y2)

[Vitamin]

ой сдается мне, что по нынешним меркам это мега тормозная процедура...

На такие мысли навел год в строке копирайта?

Я вот жду результатов тестирования тов. Sinus

[GriV]

дык это на мой взгляд не корректный тест... В диагоналях то точнее будет, ведь она:
1. самая длинная линия
2. самая сложная в рисовании

Не очень верно

Оффтоп, но может кто забыл какие глюки были в 3dMark'03? Там использовался простой подгон под тест и в результате бенчмарк вырастал за ни за что в 1,5 раза %)

Это я к чему: если в процедуре прорисовки будет отдельная процедура которая рисует диагональные линии то такой способ вызовет эээ не совсем адекватную оценку. Там что Sinus правильно говорит, надо делать рандомный тест. Я ещё более объективно быть может использовать такой тест - в течение скажем секунды рандомные линии, потом в течении секунды вертикали, потом горизонтали, потом диагонали. В конце выводить результаты по всем четырём тестам, в принципе вполне возможно рисовать вертикальные/горизонтальные линии отдельной процедурой (так же как диагонали на 45 градусов и/или на весь экран). Принципиально тест не изменится, а вот результат станет более точным.

[himik]

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

[GriV]

Додумал сейчас... надо бы ещё проверять качество линии %) мало ли какая ушлебанская процедура попадётся :-D она быть может просто будет делать RET зато будет как быстро работать!!! :-)

[himik]

хотя может быть и логичнее было-бы взять для основы теста некую готовую таблицу координат, в которой уже прорисованы несколько готовых линий, используя все направления и длины. Вот тогда и можно просто вычеслить, какая процедура рисования обрабатывает это быстрее, т.е. занимает меньше времени на вывод полной картинки из координат.
ИМХО логичнее, и рэндомность исключаем.

[GriV]

Вот ещё что подумал, там ведь дробночисленная арифметика используется - я имею в виду приращения по X и по Y для прорисовки линий. В таболичном методе, которыми очевидно пользуются быстрые процедуры очевидно это арифметика присутствует, хоть и в неявном виде. И в зависимости от того как работает счётчик переполнения будет меняться алгоритм увеличения координаты по X и по Y - это может быть округление в сторону меньшего целого, в сторону большего целого и классическое округление (от 0,5). В зависимости от этого форма линии в целом может меняться!!!
Потому имхо если уж делать тест, то самой точной должна быть признана линия, которая использует последний критерий переполнения (классическое округление). И ещё, встречались некоторые процедуры, которые в целях увеличения быстродействия рисовали линии с пустыми местами (т.е. линия имела разрыв, как пунктир).

[Advertiser]

[himik]

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

[psndcj]

еще корректнее наверно будет считать не сколько линий за фрейм - а рисовать скажем с сотню линий и считать количество затраченных фреймов...

[Lethargeek]

хотя может быть и логичнее было-бы взять для основы теста некую готовую таблицу координат, в которой уже прорисованы несколько готовых линий, используя все направления и длины. Вот тогда и можно просто вычеслить, какая процедура рисования обрабатывает это быстрее, т.е. занимает меньше времени на вывод полной картинки из координат.
ИМХО логичнее, и рэндомность исключаем.

Просто надо "среднее количество тактов на пиксель в основном цикле" проинтегрировать по всем возможным углам

[GriV]

ну есть стандартные критерии оценки производительности графической подсистемы %) например в килопикселях или в мегалиниях :-) шутко :-) количество линий - вот главная оценка.

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