| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Оптимизация кода
Вова © (2013-06-25 20:17:00)
Страницы: < 1 2 3 4 5 6 7 8 9 10 11 >
Есть процедура задачей которой является приведения пикселя любого цвета к цвету одного из диапазонов. Но скорость ее работы огорчает меня, можно ли ее как нибудь ускорить?
function almostEqual(a, b: byte): Boolean;
begin
if ABS(a - b) < 10 then
result := true
else
result := false;
end;
Function ConvertColorToRGBColorMap(color: LongInt; ColSel: String = 'None')
: TColorWithName;
var
RGBV: trgbcolor;
begin
RGBV.red := color;
RGBV.green := color shr 8;
RGBV.blue := color shr 16;
with RGBV do
if almostEqual(red, green) and almostEqual(red, blue) and
almostEqual(blue, green) then // тогда это серый или черный или белый
begin
if almostEqual(red, 255) then // белый
begin
result.color := RGB(255, 255, 255);
result.Name := 'White';
end
else if red > 120 then
begin
result.color := RGB(190, 190, 190);
result.Name := 'LightGray';
end
else if (red > 92) then // темно серый
begin
result.color := RGB(100, 100, 100);
result.Name := 'DarkGray';
end
else
begin
result.color := RGB(0, 0, 0);
result.Name := 'Black';
end // черный
end
else
begin
if (red < green) and (red < blue) and almostEqual(green, blue) and
(blue > 130) then
begin
result.color := RGB(0, 0, 255);
result.Name := 'Blue';
end // result:= rgb(0,255,255)//голубой
else if (green < red) and (green < blue) and almostEqual(red, blue) and
(red > 130) then
begin
result.color := RGB(255, 0, 255);
result.Name := 'Pink';
end // розовый
else if (blue < green) and (blue < red) and almostEqual(green, red) and
(green > 130) then
begin
result.color := RGB(255, 255, 0);
result.Name := 'Yellow';
end // желтый
else if (red > green) and (red > blue) and (red > 130) then
begin
result.color := RGB(255, 0, 0);
result.Name := 'Red';
end // красный
else if (blue > green) and (blue > red) and (blue > 130) then
begin
result.color := RGB(0, 0, 255);
result.Name := 'Blue';
end // синий
else if (green > blue) and (green > red) and (green > 130) then
begin
result.color := RGB(0, 255, 0);
result.Name := 'Green';
end // зеленый
else
begin
result.color := RGB(0, 0, 0);
result.Name := 'Black';
end
end;
if not (ColSel = 'None') then
if not (ColSel = Result.Name) then
begin
result.color := RGB(255, 255, 255);
result.Name := 'White'; //Если выборка только по одному цвету, то
//все остальные цвета переводим в белый
end
else
begin
result.color := RGB(0, 0, 0);
result.Name := 'Black'; //Если выборка только по одному цвету, то
//этот цвет переводим в черный
end
end;
Вова (2013-07-29 20:27:00) [61]
> ты меня прям обламал
> хотел продемонстрировать высший пилотаж... а ты забросил
не забросил, а отложил )
DevilDevil (2013-07-29 18:11:00) [62]> Вова (29.07.13 18:09) [147]
> Там выше где то было, но вообще я еще не делал, мне под
> него программу нужно переделывать, время пока нет на это (
ты меня прям обламал
хотел продемонстрировать высший пилотаж... а ты забросил
DevilDevil (2013-07-29 18:10:00) [63]> Вова (29.07.13 18:06) [146]
> ты же сам сказал, что по определению быстрее. Ну из того
> что я пробовал оно следует.
всё верно
в современном мире используют преимущественно 32 бита, даже если нет альфаканала
ибо проще и быстрее
"стильно модно молодёжно" хочется сказать :)
Вова (2013-07-29 18:09:00) [64]
> ok, покажи текущий код для 32 бита
Там выше где то было, но вообще я еще не делал, мне под него программу нужно переделывать, время пока нет на это (
Вова (2013-07-29 18:06:00) [65]
> > Вова (29.07.13 17:20) [143]> если 32 проще и быстрее
> работаетхочешь поговорить об этом? )
ты же сам сказал, что по определению быстрее. Ну из того что я пробовал оно следует.
DevilDevil (2013-07-29 17:44:00) [66]ok, покажи текущий код для 32 бита
Sha (2013-07-29 17:41:00) [67]> Вова (29.07.13 17:20) [143]
> если 32 проще и быстрее работает
хочешь поговорить об этом? )
Вова (2013-07-29 17:20:00) [68]
> *покажи
в 81м посте, но нафига, если 32 проще и быстрее работает.
DevilDevil (2013-07-29 15:25:00) [69]*покажи
DevilDevil (2013-07-29 15:02:00) [70]> Вова (04.07.13 01:50)
подниму ка я ветку
пока работающий вариант с циклом for по X и по Y в 24 битах
оптимизирую
а то развели тут бардак ))
Sha (2013-07-04 10:18:00) [71]
$87654321 shr 12 = $00087654
$00087654 and $00000F0F = $00000604
$87654321 and $000000F0 = $00000020
$00000604 or $00000020 = $00000624
Мы сформировали число в интервале 0..4095 (индекс цвета в нашей таблице),
комбинируя старшие ниблы каждого из трех цветовых каналов.
Порядок следования исходных ниблов в полученном числе выбран таким,
чтобы обеспечить максимальную скорость преобразования цвета в индекс.
Вова (2013-07-04 01:50:00) [72]12500670 =
10111110 10111110 10111110 shr 12 = 00000000 00001011 11101011 and $F0F =00000000 00001011 00001011
10111110 10111110 10111110 and $F0 = 10111110 10111110 10110000
00000000 00001011 00001011 or
10111110 10111110 10110000 =
10111110 10111111 10111011 = 12500923
и в чем тут смысл? да и по моему че то не так....
Sha (2013-07-03 20:42:00) [73]Сдвиг у тебя правильный )
А второй триплет, тот который на экране правее первого,
расположен в памяти по адресу на 3 больше, чем адрес первого.
Вова (2013-07-03 20:38:00) [74]нет уш. Если у нас уже готовый битмап есть, то чтобы пройти от начала до конца строки, нужно идти справа на лево получается. так что это письмо справа налево. и т.е. получается что второй триплет левее первого... но сдвиг вправо я надеюсь правильно нарисовал?) а то может у них и сдвиг вправо на самом деле влево ))
Sha (2013-07-03 20:06:00) [75]Мы, пишушие слева направо, любим стрелки вдаль к бесконечности направлять направо,
а числа записывать так, чтобы разряды с бОльшим весом располагались слева.
И это создает проблему.
Когда мы мыслим число в вакууме, с заякоренным разрядом единиц,
то чем оно больше тем левее у него левый край.
Но то же, лежащее поразрядно в бесконечной памяти уходит далеко направо.
Так что лево/право весьма относительно.
Этой проблемы не было бы, если б мы считали, что адреса растут от нуля налево.
Но как только мы начнем так считать, то сразу же появится аналогичная проблема для строк.
Наверно, поэтому никто из пишущих направо так и не считает )
Резюмируя, можно сказать, что команды SHR и SHL относятся к числу в вакууме.
И если тебе так будет проще, можешь считать,
что в памяти число вывернуто наизнанку, и левый фланг у него справа )
Вова (2013-07-03 18:38:00) [76]
> че-то ты притих )i shr 24 and $F0 - ставим нулевой байт
> второго триплета на нулевое место и оставляем в нем только
> 4 старших бита в старшем нибле,
я просто уже выпал в осадок. Я уже заметил что нет единого мнения где у чего начало и конец, натворили че попало, без картинок и ящика водки не разберешься.
11111111 11111111 11111111 11111111 shr 24 and $F0= 00000000 00000000 0000000 11110000
т.е. самый левый байт становится самым правым. это как я себе представлял, но и также я себе представлял, что именно самый правый был первым байтом второго триплета. Теперь я уже затрудняюсь себе что либо представлять (
или таки т.е. нулевой это самый правый, первый это второй справа и т.д. и т.е. самый левый на самом деле 3й )) ппц. Че за наркоман это придумывал.
Inovet (2013-07-03 06:34:00) [77]> [132] Sha © (02.07.13 21:46)
> понять, нафига их сюда впихнули
Вот.
Inovet (2013-07-03 06:33:00) [78]> [127] Rouse_ © (02.07.13 21:22)
> Оть так-же гораздо удобней:
>
> or (((i shr 16) and $FF) div 3) shl 16
Ну, как бы наоборот - путают скобки.
Sha (2013-07-02 21:46:00) [79]Я уже давно так пишу, привык.
Наоборот, скобки тормозят чтение кода.
А лишние скобки просто бесят. Потому, что пытаюсь понять, нафига их сюда впихнули, а вдруг это ошибка?
Rouse_ (2013-07-02 21:40:00) [80]Принцип понятен, но все равно не привычен (попробовал - ну не получается на автомате разбирать такие конструкции) :)
| |
