Здравствуйте, vdimas, Вы писали:

V>Раньше даже каждая надпись была отдельным окошком класса STATIC.

Да, я понял что ты имел ввиду. Подзабыл что раньше любой элемент был дочерним окном, а сейчас остались только окна самих контролов плюс пара окон для каких-то нотификаций

Здравствуйте, Evgeniy Skvortsov, Вы писали:

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

Тулбар и риббон это немного разные вещи. Тулбары и по сей день, если есть, то устроены так же как и раньше.

Товарищ утверждает что чуть не весь скрин приложения это один мега-битмап.

Здравствуйте, Ikemefula, Вы писали:

I>Товарищ утверждает что чуть не весь скрин приложения это один мега-битмап.

Фактически так.
Даже если это три-четыре битмапа, а не один, это не изменяет общего тренда.

Здравствуйте, vdimas, Вы писали:

V>Фактически так.
V>Даже если это три-четыре битмапа, а не один, это не изменяет общего тренда.

Spy открой.

Здравствуйте, Ikemefula, Вы писали:

I>Тулбар и риббон это немного разные вещи. Тулбары и по сей день, если есть, то устроены так же как и раньше.

Ну вот нашел не очень старую софтину у которой есть тулбар — дочерних окон нет.

I>Товарищ утверждает что чуть не весь скрин приложения это один мега-битмап.

Это, безусловно, перебор

Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>Здравствуйте, Ikemefula, Вы писали:

I>>Тулбар и риббон это немного разные вещи. Тулбары и по сей день, если есть, то устроены так же как и раньше.

ES>Ну вот нашел не очень старую софтину у которой есть тулбар — дочерних окон нет.

Может и так быть. Но вот в Экселе 365 пониже риббона фактически тот же тулбар. Посмотри, что там.

Здравствуйте, CreatorCray, Вы писали:

I>>Результаты на Win 2008 R2 никого не интересуют, кроме тебя одного.
CC>Твоё же мнение на этот счёт интересует очень многих, угу.

Именно. Без долей процента все юзера сидят именно на обычных лошадках, а не серверных. И софт шлифуется именно под эти лошадки, а не серверные.

Здравствуйте, Ikemefula, Вы писали:

I>Ну, не пц, а очень даже неплох относительно того же wpf с аппаратным "ускорением".
Этих я не сравнивал так что хз

Здравствуйте, Ikemefula, Вы писали:

CC>>Неправильно. OGL accelerated граифка на такой простой сцене не должна в fillrate упираться.
I>Это слишком оптимистичное заявление.

CC>>Их вообще нет смысла сравнивать. GDI+ всегда был мегатормоз.
I>И что же ты вчера не стеснялся это делать ?
Я всегда сравнивал с pure GDI без плюса. С рендерером, который сам писал. Поищи по ветке, где то оно тут было.

CC>>Вижу что юзается nvogl32.dll, но дохрена жрётся CPU вот в таком стеке:
CC>>Ээээ. Что то похоже что FPS мерялка как раз и вызывает тормоза проходя через messaging loop.
I>То есть, тормоза из за джаваскрипта ? Гы-гы.
Хз из-за чего, но похоже что время между кадрами жрёт что то ещё. В сравнении с D2D вариантом GPU тут на расслабоне.

I>То есть, ты снова берешь назад свои слова ?

Дюд, ты можешь сильно уменьшить колво энтропии просто впрямую написав какие именно слова ты имеешь в виду.

Здравствуйте, Ikemefula, Вы писали:

I>Приведи все данные, что надо — cpu, разрешение и тд и тд. Непонятно, как проверить твои высказывания.
С маком ничем помочь не могу, этого железа вне Apple ни у кого ещё нету.

Здравствуйте, Ikemefula, Вы писали:

I>Именно. Без долей процента все юзера сидят именно на обычных лошадках, а не серверных. И софт шлифуется именно под эти лошадки, а не серверные.

В плане гуя что сервер что нет — один и тот же код.
Так что разницы нету.

Здравствуйте, c-smile, Вы писали:

_>>Ты понимаешь, что алгоритм с асимптотической вычислительной сложностью O(1) вполне себе может работать медленнее алгоритма со сложностью O(N) (причём речь не о тупом фокусе типа поставить N=1, а о вполне себе больших значениях N)?
CS>Да, при некотором фиксированном n O(1) может быть хуже чем O(n).
CS>Но когда говорят в терминах big O notation и computational complexity то имеется ввиду именно функциональные зависимости — тенденции.
CS>Скорее всего именно это меня сбивает в твоих рассуждениях.
CS>Я говорю про алгоритм/принцип вообще, а ты по всей видимости говоришь про какую-то конкретную имплементацию стоящую перед твоими глазами.

Я говорю не про какую-то свою конкретную имплентацию, а наоборот про тот факт, что без чёткого описания конкретной задачи и точного описания решения невозможно сказать какой алгоритм будет эффективнее — недостаточно знания асимптотической сложности для ответа на данный вопрос. Это и есть мой основной посыл в данной дискуссии.

CS>Понятно что 100 даже тупых GPU процессоров сделают некую работу быстрее чем один CPU.
CS>Понятно что есть исключения из этого всего. Исключения настолько очевидные что не стоят упоминания в приличном обществе.
CS>Ну там принципиально алгоритм не распараллеливается или сложен для тупой GPUёвины.

Это очень упрощённая картинка, не учитывающая тот факт, что данные под рендеринг в любом случае находятся в оперативной памяти CPU.

CS>Просто с настоящим кризисом закона Мура всё что мы можем делать это экстенсивно увеличивать кол-во GPU процессоров на карточках. Это куда графика движется.
CS>Т.е. GPU это way to go.

Так я как бы не против GPU. Собственно я в своих проектах всю графику рисую через OpenGL и моя основная GUI библиотека (Qt) делает аналогично. Но как раз поэтому я вполне себе в курсе того факта, что у рисования через GPU есть свои неудобные нюансы.

_>>Если же ты это нормально понимаешь и просто считаешь что подобная ситуация не относится к раскладу в отношение между GDI и DirextX, то уже можем спокойно и предметно побеседовать на эту тему. Например посчитать сколько переходов в режим ядра и обратно будет происходить при прорисовке одной и той же картинки с помощью этих двух технологий и т.п... )
CS>"...переходов в режим ядра..." да пофигу на самом деле.
CS>Тот же Direct2D какую-то работу по растеризации делает на стороне CPU если именно это эффективнее сделать именно там.
CS>Никто же не говорит что рисовать можно только DirectX кодом и больше никак ...

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

_>>Хы, а если у меня только курсор мыши и никаких пальцев? )))
CS>А телевизор смотреть? Или у тебя забор стоит вокруг него с табличками "смотреть онли туточки" ?

Эээ что? )

Здравствуйте, CreatorCray, Вы писали:

I>>Ну, не пц, а очень даже неплох относительно того же wpf с аппаратным "ускорением".
CC>Этих я не сравнивал так что хз

Тебя очень трудно понимать, потому что пишешь обрывками и твои сообщения большей частью невозможно перепроверить.
Скажем, c-smile привел всё что надо и его слова хотя бы проверяемы, в отличие от твоих.
А вот совсем недавно ты наскакивал на GDI+ и привел в подтверждение своих слов ссылку на этот самый WPF.
И как теперь понимать твои заявления ?

Здравствуйте, CreatorCray, Вы писали:

CC>>>Их вообще нет смысла сравнивать. GDI+ всегда был мегатормоз.
I>>И что же ты вчера не стеснялся это делать ?
CC>Я всегда сравнивал с pure GDI без плюса. С рендерером, который сам писал. Поищи по ветке, где то оно тут было.

То есть, фактически получается так, что вы с c-smile говорили каждый про своё, про GDI и GDI+. Поздравляю.

Здравствуйте, CreatorCray, Вы писали:

I>>Именно. Без долей процента все юзера сидят именно на обычных лошадках, а не серверных. И софт шлифуется именно под эти лошадки, а не серверные.
CC>
CC>В плане гуя что сервер что нет — один и тот же код.
CC>Так что разницы нету.

Как мы только что выяснили, разница есть — у тебя аномальный результат и непонятно чем его можно объяснить.

Здравствуйте, CreatorCray, Вы писали:

I>>Приведи все данные, что надо — cpu, разрешение и тд и тд. Непонятно, как проверить твои высказывания.
CC>С маком ничем помочь не могу, этого железа вне Apple ни у кого ещё нету.

Снова НДА мешает И зачем ты в очередной раз приводишь сведения, которые подтверждены исключительно твоими словами ?

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, c-smile, Вы писали:

CS>>Я говорю про алгоритм/принцип вообще, а ты по всей видимости говоришь про какую-то конкретную имплементацию стоящую перед твоими глазами.

_>Я говорю не про какую-то свою конкретную имплентацию, а наоборот про тот факт, что без чёткого описания конкретной задачи и точного описания решения невозможно сказать какой алгоритм будет эффективнее — недостаточно знания асимптотической сложности для ответа на данный вопрос. Это и есть мой основной посыл в данной дискуссии.

Мы обсуждаем имплементацию некой абстрактной DrawLine(p1,p2, color, width) которая в случае DirectX/OpenGL есть опять же некая абстрактная FillQuad(p1,p2,p3,p4,color).
FillQuad это "атомарная" операция для DirectX и OpenGL и O(1) для CPU сколько бы там pixels не нарисовалось в результате.

Понятно что не все Direct2D функции настолько просто переводятся в вызовы FillMesh и FillQuad. Но базовый архитектурный принцип для Direct2D это именно быть O(1) для CPU.

CS>>Понятно что 100 даже тупых GPU процессоров сделают некую работу быстрее чем один CPU.
CS>>Понятно что есть исключения из этого всего. Исключения настолько очевидные что не стоят упоминания в приличном обществе.
CS>>Ну там принципиально алгоритм не распараллеливается или сложен для тупой GPUёвины.

_>Это очень упрощённая картинка, не учитывающая тот факт, что данные под рендеринг в любом случае находятся в оперативной памяти CPU.

Да, упрошенная. Но близкая к реалиям Direct2D — с пиксельными массивами на стороне CPU они не работают. Можно, но надо очень сильно Direct2D просить это делать.
Т.е. если правильно работать с Direct2D, то рисование не зависит от кол-ва пикселей на экране.

CS>>Просто с настоящим кризисом закона Мура всё что мы можем делать это экстенсивно увеличивать кол-во GPU процессоров на карточках. Это куда графика движется.
CS>>Т.е. GPU это way to go.

_>Так я как бы не против GPU. Собственно я в своих проектах всю графику рисую через OpenGL и моя основная GUI библиотека (Qt) делает аналогично. Но как раз поэтому я вполне себе в курсе того факта, что у рисования через GPU есть свои неудобные нюансы.

Нюансы (a.k.a. implementation details), да.

И кстати Qt из-за того что она/он/оно приколочено гвоздями к OpenGL будет послабже чем Direc2D/DirectX.
У sciter есть как Direct2D так и Skia(исп. OpenGL) backends — сравнивать приходится постоянно. Не думаю что Skia (google) и rasterizer в Qt как-то уж сильно отличаются.
В OpenGL какие-то проблемы с renderbuffer — offline buffered rendering в отдельных случаях нужен. Я обсуждал возможную имплементацию Push/PopLayer с Mikko Mononen (автор NanoVG), он был даже что-то сделал. Но он сказал что "OpenGL's renderbuffer sucks".

_>Не пофигу, потому что переход в режим ядра — это весьма и весьма тяжело. И этого дела при рисование через GPU гораздо больше, чем при рисование в память (где оно собственно только одно финальное).

И в том и в том случае пересылка (переход в режим ядра?) делается условно говоря один раз:

— Direct2D -> пересылка vertex data (not dependent on number of pixels — O(1))
— GDI -> пересылка bitmap data (dependent on number of pixels — O(N))

_>>>Хы, а если у меня только курсор мыши и никаких пальцев? )))
CS>>А телевизор смотреть? Или у тебя забор стоит вокруг него с табличками "смотреть онли туточки" ?

У жены-орлицы понимаешь дальнозоркость, а у меня близорукость. Т.е. она видит на телевизоре "отдельные лампочки". Что-бы ей было нормально с того дивана (ака забор) его смотреть должен быть high-DPI device.
Иначе телевизор надо уносить фиг знает куда чтобы "угловой размер отдельных лампочек" уменьшить. Но в этом случае я его смотреть не смогу.

Т.е. high-DPI это суровая правда семейной жизни.

Здравствуйте, vdimas, Вы писали:

CS>>Проблема в том что и AGG и GDI растеризация (что не есть BitBlt, sic!) это всегда O(N) complexity (N — количество пикселей на экране).
CS>>Т.е. имеет крайне ограниченное применение в современных desktop.

V>Тоже неправда. Линии/прямоугольники/полигоны и т.д. рисуются в GDI одной командой, то бишь, O(1).

... the BitBlt API was hardware accelerated and most other GDI operations were not.

GDI maintains its resources, in particular bitmaps, in system memory by default. Direct2D maintains its resources in video memory on the display adapter. When GDI needs to update video memory, this must be done over the bus, unless the resource is already in the aperture memory segment or if the operation can be expressed directly. In contrast, Direct2D can simply translate its primitives to Direct3D primitives because the resources are already in video memory.

Comparing Direct2D and GDI Hardware Acceleration

Здравствуйте, c-smile, Вы писали:

CS>>>Делать весь Office в C# не реально по многим причинам. Собственно по тем же что создание HTML/CSS renderers на managed языках и средах. Попытки неоднократные были и в Java и в C# — не взлетело ни разу.
S>>Почему нельзя? Можно, только железо нужно соответствующее.
CS>Ну вот тебя самого ничего в твоей фразе не цепляет?
CS>Смотри: имеем сейчас native имплементации HTML/CSS которые работают на существующем железе. Но вот для C# (Java, whatever) имплементации HTML/CSS нужно железо в разы (а во сколько раз кстати?) лучше.
CS>Выводы сделаешь сам?
Я как-то так и не увидел толковых попыток HTML/CSS renderers на managed языках вообще (да и на нэйтиве их не так уж много). По-моему попытки провалились, в первую очередь потому, что это просто over дохрена работы, и имхо, ты вообще единственный, кто в одиночку осилил сделать что-то существенное в этом направлении.

Здравствуйте, c-smile, Вы писали:

V>>Тоже неправда. Линии/прямоугольники/полигоны и т.д. рисуются в GDI одной командой, то бишь, O(1).

CS>

CS>... the BitBlt API was hardware accelerated and most other GDI operations were not.

Это ошибочная цитата и тебе уже не раз об этом говорилось.


CS>

CS>GDI maintains its resources, in particular bitmaps, in system memory by default.

By-default на моей кухне газ выключен. Однако, я запросто готовлю на газе, когда мне надо.
Вопросы?