> не обращаясь к другим источникам информации.


Честно говоря хваленный неоднократно тут Фэнь Юань вообще избегает данной темы, так что куда мне уж тут.
А судьи кто?

> Игорь Шевченко ©   (26.03.08 21:33) [156]


Вот то что поддерживает устройство по тексту.

procedure TForm1.Button1Click(Sender: TObject);
const CONST_TECHNOLOGY:array[DT_PLOTTER..DT_DISPFILE] of string=('DT_PLOTTER','DT_RASDISPLAY','DT_RASPRINTER','DT_RASCAMERA','DT_CHARSTRE AM','DT_METAFILE','DT_DISPFILE');
     CONST_TEXTCAPS:array[0..16] of string=(
               'TC_OP_CHARACTER','TC_OP_STROKE','TC_CP_STROKE','TC_CR_90',
               'TC_CR_ANY','TC_SF_X_YINDEP','TC_SA_DOUBLE','TC_SA_INTEGER',
               'TC_SA_CONTIN','TC_EA_DOUBLE','TC_IA_ABLE',
               'TC_UA_ABLE','TC_SO_ABLE','TC_RA_ABLE','TC_VA_ABLE',
               'TC_RESERVED','TC_SCROLLBLT');
var dc:Thandle;
   ATEXTCAPS:DWORD;
   i:integer;

procedure GetTextCap(IDX:DWORD);
begin
if LONGBOOL((ATEXTCAPS AND (1 shl IDX))) then Memo1.Lines.add(CONST_TEXTCAPS[IDX]);
end;

begin
dc:=GetDC(handle);
Memo1.lines.add(CONST_TECHNOLOGY[GetDeviceCaps(dc,TECHNOLOGY)]);
Memo1.lines.add('NUMFONTS '+Inttostr(GetDeviceCaps(dc,NUMFONTS)));
ATEXTCAPS:=GetDeviceCaps(dc,TEXTCAPS);
for i:=0 to length(CONST_TEXTCAPS)-1 do GetTextCap(i);
end;

ReleaseDC естественно.

> Вы не ответили на вопрос. Зачем проводить анализ изображение
> в случае программной отрисовки?


Еще раз - адаптер умеет выводить текст сам. Драйвер адаптера об этом осведомлен. Ты же утверждаешь, что весь вывод производится на bitmap, который ты выбрал по GetCurrentObject из DC, а потом этот битмап пересылается в адаптер. Как в этом случае используются возможности адаптера по выводу текста ?

> oxffff ©   (26.03.08 22:10) [160]


Тыкаю носом в Феня Юаня стр. 119. Он пишет то же самое о чем я говорю.

Создается впечатление, что кто плохо не внимательно читал.
А кто вообще не читал и ему не мешает.

oxffff ©   (26.03.08 22:13) [161]

Уважаемый, а где собственно доказательства твоих умозаключений из [146] ?

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

> Еще раз - адаптер умеет выводить текст сам. Драйвер адаптера
> об этом осведомлен. Ты же утверждаешь, что весь вывод производится
> на bitmap, который ты выбрал по GetCurrentObject из DC,
> а потом этот битмап пересылается в адаптер. Как в этом случае
> используются возможности адаптера по выводу текста ?


Я вам 10 раз повторяю, что поверхность может быть создана адаптером в его памяти, исходная поверхность из RAM копируется в VRAM. Происходит аппаратная операция. И итоговая поверхность возвращается или не возращается в RAM. Мы же с вами это уже обсудили постов 60 назад.

> Игорь Шевченко ©   (26.03.08 22:27) [165]


Перечитайте заново Юаня, судя по всему вы пропустили некоторые моменты.
Стр.119-122.
И я тоже обязательно его прочитаю, во всяком случае добавлю в копилку еще знаний. За Юаня спасибо, прикуплю обязательно.

oxffff ©   (26.03.08 22:25) [164]


> стр. 119. Он пишет то же самое о чем я говорю.


А процитировать не затруднит ? А то у меня книжки сейчас под рукой нету, в страницу не могу посмотреть.


> Тыкаю носом


И повежливее, дружок, повежливее

> Я вам 10 раз повторяю, что поверхность может быть создана
> адаптером в его памяти


Доказательства в студию

> И повежливее, дружок, повежливее


Это не вам лично. :)

Уж не обижайтесь. А то Юань Юань, сказали бы где прочитать.
И тема закрыта была. Звиняйте. :)

У меня скан из инета. И то стр. 119 и 122.
120 и 121 нет.

Сейчас полную версию пытаюсь найти

> Игорь Шевченко ©   (26.03.08 22:32) [169]
>
> > Я вам 10 раз повторяю, что поверхность может быть создана
>
> > адаптером в его памяти
>
>
> Доказательства в студию


DrvCopyBits EngCreateDeviceSurface

> EngCreateDeviceSurface


Это я в курсе вообще-то. Это вообще-то функция Win32k.sys, которая вызывает соответствующую функцию драйвера, и которая поверхность к битмапу в DC никоим боком не относится.

> Игорь Шевченко ©   (26.03.08 22:46) [172]


Интересно а про бит гранулярности вы тоже знаете и про IRQL? :)
Так что предлагаю без лишних "это я тоже знаю". А зачем спрашиваете?.
Ну да ладно теперь к делу.

Итак мы с вами в предыдущих постах сошлись во мнении, что существует некая общая поверхность, окном в которую является window DC битмап.
Также мы выяснили (стр.119-122, 120-121стр. у меня нет), что в процессе драйвер може создавать свои поверхности, а также поверхности могут быть созданы в RAM памяти управляемые GRE.
Так же там написано, что результат программных и аппаратных операций смешивается.
Таким образом можно сделать вывод, что window DC битмап является окном на одну из таких поверхностей (а именно итоговую). Но процессе ее получения могут быть созданы несколько GRE и device managed поверхностей.
Теперь вопрос, вас еще что-то не устраивает?

oxffff ©   (26.03.08 22:59) [173]


> Итак мы с вами в предыдущих постах сошлись во мнении, что
> существует некая общая поверхность, окном в которую является
> window DC битмап.


Нет, не сошлись. Именно это я и прошу доказать.

Я имею мнение, что существует поверхность растра, для устройства, на которой в итоге и производится рисование, как методами GRE (ядерная часть GDI)m так и методами адаптера, которые методы вызываются общими фукциями для ядерной части GDI.


> Также мы выяснили (стр.119-122, 120-121стр. у меня нет),
>  что в процессе драйвер може создавать свои поверхности,
>  а также поверхности могут быть созданы в RAM памяти управляемые
> GRE.


В этом сходимся, все верно.


> Таким образом можно сделать вывод, что window DC битмап
> является окном на одну из таких поверхностей (а именно итоговую).
>  Но процессе ее получения могут быть созданы несколько GRE
> и device managed поверхностей


Нельзя сделать вывод. Я специально смотрел на битмап у DC разынх окон. Еще раз повторю, что у окон класса, например, tooltip_class32 это вполне валидный битмап, с размерами.

Со стилем класса CS_SAVEBITS он не соотносится.

Мдя... А кто-то еще в немастерстве весь форум за исключение Сергея М. упрекал... От оно как оказывается...

> Rouse_ ©   (26.03.08 23:09) [175]


Ну тебя лично я уже на немастерстве подлавливал.
Ты насколько помню передачей параметра и работой c EAX напортачил.
Да и где твои работы по расширению возможностей языка?

> А судьи кто?


Никаких судей, совершенно верно. Никаких претензий.
Самому просто интересно было бы об этом узнать, но в этой ветке пока очень мало конкретных фактов. Правда, со стороны Игоря мнение ощущается гораздо более подтвержденным (ничего личного).

Fantasist...   (26.03.08 23:16) [177]

Очевидно мне надо зарегистрироваться под другим ником

> Нет, не сошлись. Именно это я и прошу доказать.
>
> Я имею мнение, что существует поверхность растра, для устройства,
>  на которой в итоге и производится рисование, как методами
> GRE (ядерная часть GDI)m так и методами адаптера, которые
> методы вызываются общими фукциями для ядерной части GDI.
>


Давайте определять местоположение итогового растра.
Это поверхности видеопамяти. А поскольку device формат может не является DIB форматом, то и получить его описание через вызов упомянутой функции приводит к промаху.


> Нельзя сделать вывод. Я специально смотрел на битмап у DC
> разынх окон. Еще раз повторю, что у окон класса, например,
>  tooltip_class32 это вполне валидный битмап, с размерами.
>


Для небольших областей, не имеет смысл вызывать аппаратные функци, если вызов сравним по затратам с программной отрисовкой. И не будет penalty для перекачки VRAM<->RAM преобразования формата в DIB и обратно. Поэтому такая поверхность может быть кеширована в GRE поверхности которая DIB и соотвественно вызов Getobject успешный.
А возможно используется поверхность последней операции. которая может быть пребуфером в RAM или VRAM(но не являться front поверхностью).

Доказать это можно только посидев в отладчике ядра и отследив весь IRP стек.
У вас есть время? У меня его нет.