Народ а почему мелкософт не хочет переписать GUI

← →
Style (2003-12-22 21:02) [0]

Используя те же принципы что и dxdraw?
Что бы все виндовые кнопочки и пимпочки рисовались быстрее?

Или я чего не допонимаю??

← →
Игорь Шевченко (2003-12-22 21:07) [1]

> Или я чего не допонимаю??

Совершенно верно.

← →
Rouse_ (2003-12-22 21:13) [2]

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

← →
Style (2003-12-22 21:15) [3]

Игорь Шевченко ©

Нет то что Dxdraw использует GUI это понятно.
т.е. тот же API
BitBlt и другие функции.

Ну а если конкретно? Почему ГУИ такой тормозной.

Вот есть такой компонентик TDXPaintBox - в DelphiX почему
если я сделаю свой грид и рисовать буду на DIB поверхности то все графика работает на порядок шустрее?? Нет таких явных тормозов с перерисовкой??

← →
DVM (2003-12-22 21:22) [4]

> Вот есть такой компонентик TDXPaintBox - в DelphiX почему
>
> если я сделаю свой грид и рисовать буду на DIB поверхности
> то все графика работает на порядок шустрее?? Нет таких явных
> тормозов с перерисовкой??

Так проблема не в API, а в некоторых компонентах Delphi. Не надо валить в одну кучу все.
BitBlt и так использует ускорение видеоадаптера по возможности, насколько мне известно, и скорость ее работы огромна. По крайней мере я не встречал случаев, когда она мне не успевала что-то отрисовать.
Зачем нужен DirectX там где и без него все прекрасно работает.

← →
y-soft (2003-12-22 21:32) [5]

Не нужны рюшечки - так кто мешает не использовать их при написании программы. Можно использовать консоль, или вообще писать без интерфейса :)

← →
Style (2003-12-22 21:35) [6]

2DVM

т.е. это беда компонентов Borland?

Допустим у нас есть форма с черным фоном и TShape(100x100). Я перемещаю TShape красного цвета меняя в цикле его координаты - сразу очивидно мерцание данного объекта.

Неужели так долго рисуется квадрат??

← →
SPeller (2003-12-22 21:44) [7]

Тут точно не в Дельфи и не в компонентах проблема. Ответ [1] - всем ответам ответ :)

← →
Style (2003-12-22 21:46) [8]

Если опять же на WinAPI
сделать прорисовку с закрашиванием на форме черного цвета?

var
dc : hdc;
cb: hbrush;
hb: hbrush;
i: integer;
begin

dc := getdc(Form1.Handle);
cb := CreateSolidBrush(RGB(0,0,0));
hb := CreateSolidBrush(RGB(255,0,0));
for i := 1 to 200 do
begin
selectobject(dc,cb);
rectangle(dc,100+i-1,100,200+i-1,200);
selectobject(dc,hb);
rectangle(dc,100+i,100,200+i,200);
sleep(1);
end;
deleteobject(hb);
deleteobject(cb);
end;

Опять же у нас появляется мерцание.

← →
Style (2003-12-22 21:54) [9]

Так вот в DirectX - идет не постоянная перерисовка на экран а все происходит на Поверхности(IDirectDrawSurface) и только затем Surface рисуется на экране - помоему делает это Flip

так же сделано и в TDXPaintBox - TDIB в делфиX - компонент не имеет никакого отношения к DirectX . После того как я заполняю канву я вызываю метот Paint и итговое изображение прорисовывается на экране?

Почему бы Windows не придерживаться тем же правилам. Т.е. обрабатывать сначала все в памяти затем выкидывать на экран?

← →
Игорь Шевченко (2003-12-22 21:57) [10]

Style © (22.12.03 21:46)

Есть такое волшебное слово DoubleBuffered. Суть его в том, что рисование происходит в области памяти, а потом одним BitBlt все нарисованные битики из этой области отправляются на экран. И никакого мерцания.

---
LMD

← →
Style (2003-12-22 21:59) [11]

Кстати уже давно хочу переписать ряд стандартных компонентов (особенно ДБгрид) с использованием канвы из TDIB - просто есть ряд рабочих станций со старым Win95 и процами не больше 166 - вот там очень заметны тормоза с перерисовкой.

← →
Mihey (2003-12-22 22:12) [12]

> Вот есть такой компонентик TDXPaintBox - в DelphiX почему
если я сделаю свой грид и рисовать буду на DIB поверхности то все графика работает на порядок шустрее?? Нет таких явных тормозов с перерисовкой??

О мой бог! Только не DelphiX. Тормоза обеспечены на всю жизнь! Это всё фигня. Не требуется это таким приложениям, как Word и прочие. Даже в MediaPlayer этого нет.

Мелкософт улучшает GUI, например, через GDI Plus. Вообще, те же кнопочки можно без мерцаний вывести обычными средствами.

← →
Style (2003-12-22 22:17) [13]

Игорь Шевченко ©
>>DoubleBuffered

Спасибо. понял...

Попробую с гридом может поможет.

А можеть стоит через TDIB сделать? Все равно мне свой грид нужно писать полностью?

← →
Style (2003-12-22 22:20) [14]

>>О мой бог! Только не DelphiX. Тормоза обеспечены на всю >>жизнь!
>>Это всё фигня. Не требуется это таким приложениям, как Word и >>прочие.

А что за тормоза конкретнее можно??

← →
Юрий Федоров (2003-12-22 22:38) [15]

>>Автор ветки
В "длинном горне" будет именно так

← →
Style (2003-12-22 22:44) [16]

Юрий Федоров © - хм.. интересно

Бум ждать когда выйдет нормальная версия.

← →
Style (2003-12-22 22:48) [17]

Вот у NVIDIA есть такая штука - как аппаратное ускорение развертывания окон.

Заметно ускоряет все эти виндовые примочки. Можеть в скором будущем сделают более интересную аппаратную поддержку Windows GUI. ???

← →
Mihey (2003-12-22 22:55) [18]

> А что за тормоза конкретнее можно??

А то, что у меня PII 400 Mhz и с DelphiX работать невозможно из-за тормозов. Каждая загрузка приложения с DelphiX очуществляется гораздо дольше - нужно кучу всего загрузить. Я этот пакет уже давно забросил ввиду его малосостоятельности. Если будет открыто не одно, а несколько окон - тормоза обеспечены на любом окне.

Не смеши этим. Глупая идея. Только в играх делается такой интерфейс - черех настоящий DirectX, а не оболочки. Если нужна быстрая перерисовка без мерцаний - то лучше уж переделать все компоненты на Graphic32, а это вполне возможножно. Ускорение через MMX, любой вид блендинга, все эффекты, независимость от видеоаппаратуры.

← →
Style (2003-12-22 22:58) [19]

Mihey © - я имею введу не DirectDraw, а только DXDIB и DXPAINTBOX который никакого отношения к DirectXу не имеет.

← →
Zergling (2003-12-23 07:25) [20]

> который никакого отношения к DirectXу не имеет.

Это почему? Когда они как вроде являются оберткой для DirectX.
И если вдруг перелапатить GUI, как обеспечить совместимость готовых программ с предыдущими версиями Windows

← →
Style (2003-12-23 07:41) [21]

первый раз слышу - оберткой для DirectX.
может для DelphiX?

← →
Zergling (2003-12-23 07:58) [22]

Style © (23.12.03 07:41) [21]

>> может для DelphiX?

Всех мам и пап перебирать будем? В конечном итоге всеравно и DelphiX будет являтся оберткой для DirectX :^)

← →
Style (2003-12-23 08:37) [23]

2 Zerling -
Никакого отношения к DX эти комопоненты не имеют..
DXDIB - просто регистрирует новый формат

TPicture.RegisterClipBoardFormat(CF_DIB, TDIB);
TPicture.RegisterFileFormat("dib", "Device Independent Bitmap", TDIB);
finalization
TPicture.UnRegisterGraphicClass(TDIB);

как TSharedImage

И просто этот формат добавлен в модуль DxDraw, и никакие API функции для работы с DIB не экспортируются из ddraw.dll, потому что нет в derictX такого. Это приблуда создателя DelphiX.

← →
Murad (2003-12-23 08:47) [24]

2Style ©
Ускорение графики - не задача операционной системы, т.к.
зачастую это ускорение связано с расходом ресурсов. Есть
несколько способов ускорения для которых в WinAPI(больше всего
в GDI) есть необходимый инструментприй. Дальше программист
сам решает чем он готов платить за скорость. Кстати... двойная
буферизация не дает выигрыша по скорости... она только
сглаживает эффект мерцания.

← →
Style (2003-12-23 08:57) [25]

Murad © -
>>она только сглаживает эффект мерцания.

ну теоретически скорость тоже немного возрастет, что быстрее
1 раз сбросить буфер на экран или 5 ??

← →
Murad (2003-12-23 09:08) [26]

2Style ©
Совершенно согласен. Просто многие реализуют "прямую" двойную
буферизацию, когда идет просто отрисовка на буфер и
только когда он полностью готов его заливают на DC

← →
Zergling (2003-12-23 09:08) [27]

Style © (23.12.03 08:37) [23]
Ладно, уболтал :)
В Style © (23.12.03 07:41) [21] ты меня поправил
> может для DelphiX?
после чего у меня и последовал вывод
Zergling © (23.12.03 07:58) [22]

Murad ©
>> Есть несколько способов ускорения для которых в WinAPI
>> (больше всего в GDI) есть необходимый инструментприй

Если почитать Фень Юаня "Программирование графики в Windows", то он тоже особо эту GUI с ее стандартным инструментарием (не весь кончно инструмент поганый, но в некоторых местах..) нехвалит. Поэтому в свой книге предоставляет более оптимальный вариант реализации той или инной процедуры которая работает на порядок эффективней. К примеру по слухам MS долго офицально не признавала недоработку функций Set и GetPixel. Признала только через некоторое время. Так эти функции и недоделали. Правда или нет по поводу этого слуха незнаю. Может кто подтвердит или опрвергнет.
Отсюда вывод: хочешь оптимальное решение - думай и пиши сам.

← →
Murad (2003-12-23 09:13) [28]

2Zergling
> хочешь оптимальное решение - думай и пиши сам.
Я об том и говорю :)))

← →
Style (2003-12-23 09:14) [29]

>>не признавала недоработку функций Set и GetPixel
Это что еще за недоработка?

Eсли мы с таким тормозным интерфейсом будем за каждой точкой обращаться к экрану то Естественно SetPixel и GetPixel будут работать медленно.

← →
Zergling (2003-12-23 09:28) [30]

Style © (23.12.03 09:14) [29]

Послухам, а может и из книги Фень Юаня вычитал: реализованны там всякие тупые левые проверки. В книге Фень Юаня представлен его собственный вариант Get и SetPixel при обращении к точки растра изображения на прямую, и работает это чудо очень быстро! (в несколько десятков раз - взависимости еще и от скорости PC)

← →
Style (2003-12-23 09:33) [31]

2 Zerling

А можешь код показать?? Интересно посмотреть

← →
Думкин (2003-12-23 10:02) [32]

← →
Style (2003-12-23 10:04) [33]

← →
REA (2003-12-23 10:24) [34]

Я в свое время когда DirectX появился хотел обертку/надстройку написать для него для автоматизации разработки интерфейса в играх и че то потом лень стало и документации не хватало.

← →
NailMan (2003-12-23 10:42) [35]

Че вы паритесь? Почитали бы хоть новости. Windows Longhorn будет требовать видеокарту не НИЖЕ Radeon 9700 на юзание своего GUI. Там весь интерфейс будет на DX9 и выше.

Так что забейте, расслабьтесь и айда на всеобщий апгрейд.

← →
Style (2003-12-23 10:44) [36]

2 Rea, я еще в C++ Buildere под DirectX игрухи писал.

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

Посмотрим что там с Windows LongHorn выдет.. Хотя как всегда новые баги зародятся :)

← →
Style (2003-12-23 10:48) [37]

2 NailMan ©

похоже на ГОН!

Зачем такие ресурсы, если бы Оперативки больше заюзал бы - я бы поверил еще!

Хотя и для Гуи можно использовать немеренные объемы видеопамяти на современных картах

← →
NailMan (2003-12-23 11:18) [38]

Style ©
http://www.overclockers.ru/news/newsitem.shtml?category=1&id=1072086323

22 декабря 2003

Для нормальной работы в Longhorn потребуется видеокарта не ниже Radeon 9700

О "стратегической важности" поддержки современными графическими решениями DirectX 9.0 мы узнали полгода назад. Следуя классическому амплуа инициатора "гонки технического перевооружения", компания Microsoft объявила о совместимости графического интерфейса операционной системы Windows Longhorn с технологиями DirectX 9. Точнее говоря, непосредственно DirectX 9 поголовно не навязывался, для базовых функций была предусмотрена обратная совместимость с DirectX 7, но претендовать на звание "продвинутого пользователя" в таком случае владелец слабенькой системы не мог.
...

Это опасение подтверждают представители ATI, которые со ссылкой на Microsoft заявляют следующее. Для полноценной работы в Longhorn действительно потребуется видеокарта класса не ниже Radeon 9700. Заметьте, это выпущенное полтора года назад решение до сих пор не сдает позиций и никак не претендует на звание бюджетного. Что уж говорить о более слабых видеочипах, имеющих по четыре пиксельных конвейера и 128-битную шину памяти...

Вобщем все вполне официально.

← →
Style (2003-12-23 11:26) [39]

2 NailMan ©
Хотя как я понимаю LH будет использовать аппаратную поддержку DX9
тогда все верно, либо Geforce fx либо Radion не ниже 9700!

Но наверняка оставят и старый гуи??

← →
Волк-Призрак (2003-12-23 12:41) [40]

Style ©
Но наверняка оставят и старый гуи??
Который станет надстройкой над новым.
Вроде Carbon и Cocoa в OS X 10.3 Jaguar.
Проблема "осевых революций" заключается
в том что от того момента, когда
производители железа вводят ось-спешиал-фичез:),
до появления такого железа у разнесчастного
российского юзверя достаточных бабок на железо
и _желания апгрейднуть комп_ проходит больше
времени, чем требуется для новой "осевой революции".
Имено по этому на презентации лонгхорн была запущена
первой не квака XXXL а досовая табличная редакталка.
BackWarD Compatibility ForEwer:)

Народ а почему мелкософт не хочет переписать GUI Найти похожие ветки