Здравствуйте, Mamut, Вы писали:
M>Не понимаю. Почему вот этот тупейший код:
M>

M>        var table = $(document.body).append('<table>');
M>        for(var i=0; i < 20; i++){
M>            var tr = $('<tr>');
M>            for(var j=0; j < 20; j++){
M>                var td  = $('<td>');
M>                var chk = $('<input type="checkbox">');
M>                chk.bind('click', function(){$(this).parent().css('background-color', $(this).is(':checked') ? 'red' : 'white')});
M>                td.append(chk);
M>                tr.append(td);
M>            }
M>            table.append(tr);
M>        }
M>

M>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить.

M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?

Давайте мух от котлет...
В приведенной ссылке автор написал 400 про чекбоксов в гриде и тормоза. И все. Как эти тормоза проявляются и прочая — неизвестно.
Пока единственное, что удалось возпроизвести это то, что при создании 400 чекбоксов форма при ресайзе жрет процессор и не всегда поспевает за мышкой. (тупо хватаем мышкой правый нижний угол и начинаем судоржно таскать)
В остальном — кликанье, изменение состояния чекбокса — тормозов нет.
В этом плане приведенный вами выше пример ведет себя практически так же как и в WPF (браузер — Chrome).
Кстати, в той же теме чуть ниже отписались, что в VCL поведение идентичное.

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

M>Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит.
Блин, а я старался. Ну, хорошо, демагогия так демагогия.

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

S>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.

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

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

S>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
MM>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.

скыдыщь

M>>Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит.
MM>Блин, а я старался. Ну, хорошо, демагогия так демагогия.

А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.

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

S>>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
MM>>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.
S>скыдыщь
Если я правильно понял, там кастомный вид создают картинками.
Как это будет работать на мониторах с разной настройкой DPI?
Как это учитывает цветовую схему ОС?

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

M>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
Вот здесь

Автор: syrompe
Дата: 15.03.12

очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.

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

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

S>>>>HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
MM>>>Какие, например? Я с HTML почти не сталкиваюсь, так что могу и не знать.
S>>скыдыщь
MM>Если я правильно понял, там кастомный вид создают картинками.
MM>Как это будет работать на мониторах с разной настройкой DPI?
MM>Как это учитывает цветовую схему ОС?

В WPF в 90% случаев иконки тоже делают картинками (PNG).
В HTML есть Canvas — так что тоже можно нарисовать в векторе.
В HTML тоже можно размеры задавать в Pixel independent единицах.
А как WPF учитывает цветовую схему ОС?

M>>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
MM>Вот здесь

Автор: syrompe
Дата: 15.03.12

очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.

Ладно, будем ждать объяснений

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

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

M>>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.
MM>Вот здесь

Автор: syrompe
Дата: 15.03.12

очень правильный камент. Не фига непонятно из примера, что там тормозит. Я пробовал прикинуть, что может создавать нагрузку с учетом архитектуры WPF, а сейчас накидал грид 20 x 20 и не тормозит чего-то. Что делать, теперь не знаю.

Меня вот тоже прям заинтересовал вопрос, набросал на коленках пример. Ничего не тормозит.
Скрин: http://dl.dropbox.com/u/36488155/DataGridTest2.png
Кто хочет, может поиграться.
Проект: http://dl.dropbox.com/u/36488155/DataGridTest2.7z (VS 2010)
Exe: http://dl.dropbox.com/u/36488155/DataGridTest2.exe.7z (NET 4 Client Profile)

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

S>В WPF в 90% случаев иконки тоже делают картинками (PNG).
Так речь же не об иконках. Речь о ControlTemplate, возможности которого создают нехилый оверхэд. К слову, у нас в проекте все картинки — векторные Drawing и Geometry.

S>В HTML есть Canvas — так что тоже можно нарисовать в векторе.
Вот пускай мне предоставят пример, где все чекбоксы нарисованы Canvas-ом в векторе

S>В HTML тоже можно размеры задавать в Pixel independent единицах.
Да, но в готовых PNG не задашь.

S>А как WPF учитывает цветовую схему ОС?
Шаблоны контролов используют DynamicResource на ключи из SystemColors.

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

N>Какая модель процессора? Какая ОС?
модель уже не вспомню. А от OС cpuid не зависит.

N>(вообще-то очень слабо верится, слишком очевидный ляп.)

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

F>легко собирается, если нет привязок к винде или не-дотнет штукам..
F>даже я писал на шарпах под линухом, а потом запускался под виндами..
А наоборот?

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

S>На чём тогда писать сайты и большие сайты?
На перле?

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

M>>>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот?
S>>Нет

M>Так в чем вопрос? Mono и MS .net Framework реализуют один и тот же стандарт. В MS .net Framework просто дополнительные windows-зависимые библиотеки. Так же, как есть платформо-зависимые библиотеки для С++

M>Но я повторяюсь. Это все было пройдено два-три года тому назад.

И тогда же мы выяснили что моно — кроссплатформенен, а дотнет — нет.

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

F>>легко собирается, если нет привязок к винде или не-дотнет штукам..
F>>даже я писал на шарпах под линухом, а потом запускался под виндами..
S>А наоборот?

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

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


Ф>>> именно библиотеки хорошо характеризуют платформу, на которой они написаны
М>>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.

N>А так ещё лучше — хотя надо откуда-то изображения галочек взять. Это ж целого дизайнера привлекать.

Оу. Делаем одну галочку на чем вам нравится. Принтскрин. Паинт, или что там еще. Вырезаем квадратик. Делаем то же со всем стадиями галочки, которые нам нужны. Вставляем в ресурсы приложения, рисуем картинку. Профит!

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


S>>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.

N>Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.

Да и, вобще-то, на кой черт компилить все подряд? Большинство кода занимает от силы сотые доли процентов проца при выполнении, но этого кода в приложении большинство. Его компиль-не компиль, ничего в производительности не выиграешь.

Кстати, отчасти потому на серверах и распространились платформы с байткодом и джитом. Времени у последнего на выявление узких мест предостаточно, а все остальное просто нет смысла компилить в нативу. А десктопные приложения на той же жабе запускаются всегда в "клиентском" режиме, т.е. без джита вообще, ибо бессмысленно. Кому надо — ключик укажет явно, если есть узкие места(т.е. серьезные рассчеты).

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


M>А ты сам этого не видишь? Понимаешь, 20x20 чекбоксов, как их ни рисуй — это настолько мизер, что даже удивительно, что торможение грида пытаются объхяснить чем угодно, лишь бы не кривизной фреймворка.

Даже не в в плохой час упомянутая джава, у которой это и контролы с каждым окошком для каждого(прада, внутренним жабовским, а не нативными, но плюс ли это?), и сложная модель для отрисовки запрашивается каждый раз, и еще и рисуется это на канвасе интерпритатором, без всякого ускорения, на этом если и притормаживает, то только из-за пресловутой отрисовки на канвасе без нативы, точечка-по-точечке в интерпритируемом коде. А то и вовсе не тормозит, смотря какой комп. Чего там напихали в тот ВПФ, у которого отрисовка вообще видеокартой идет, я не знаю.

M>>>>Ты будешь возражать, что найдутся проекты, которые не собираются под gcc, но собирающиеся под Microsoft C++ compiler и наоборот?
S>>>Нет

M>>Так в чем вопрос? Mono и MS .net Framework реализуют один и тот же стандарт. В MS .net Framework просто дополнительные windows-зависимые библиотеки. Так же, как есть платформо-зависимые библиотеки для С++

M>>Но я повторяюсь. Это все было пройдено два-три года тому назад.

S>И тогда же мы выяснили что моно — кроссплатформенен, а дотнет — нет.

Это выяснил ты. Но то, что выясняют для тебя твои фантазии, ничего общего с реальностью не имеет. Это мы тоже выяснили. Более того, уже в этом топике тебе несколько человек написало примеры, что твои фантазии ничего общего с реальностью не имеют, я в очередной раз по кругу написал тебе, что ситуация ничем не отличается от С++, но ты, судя по всему, так и не вылазишь с ех маковых полей, которые ты так упорно всем приписываешь.