Есть ли будущее у DELPHI?
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.43] |
|
|
Правила раздела:
| Страницы: (245) « Первая ... 118 119 [120] 121 122 ... 244 245 ( Перейти к последнему сообщению ) |
Есть ли будущее у DELPHI?
|
Сообщ.
#1786
,
|
|
|
|
Главное, чтобы увеличение производительности было быстрее, чем увеличение объемов. |
|
Сообщ.
#1787
,
|
|
|
|
Цитата [S]mike @ Кстати, может продолжить старую добрую традицию - сделать бенчмарк плюсов, джавы, шарпа, дельфей...? Давай, только не сферический алгоритм в вакууме, а вполне жизненный и рабочий Добавлено Цитата [S]mike @ Как показали мои собственные тесты в этой теме: второе - это неправда. Джава быстрее или на уровне Дельфей. Шарп бывает немного отстает, но бывает и быстрее Дельфей. А если еще использовать специфичные классы и методы - то, думаю, первенство Дельфей можно будет легко оспорить. Второе скорее всего правда, но оно гораздо менее важно чем первое Добавлено У меня в принципе есть задача, может показаться интересной |
|
Сообщ.
#1788
,
|
|
|
|
Цитата --Ins-- @ Давай, только не сферический алгоритм в вакууме, а вполне жизненный и рабочий Цитата [S]mike @ Первое, что приходит на ум - что-то карточное. Например, симулятор какой-то простой карточной игры: очко, дурак... Не подходит? Энамы - очень удачный механизм для карточных игр. Как для рангов и мастей, так и для самих карт. Цитата --Ins-- @ Второе скорее всего правда, но оно гораздо менее важно чем первое Хорошо, допустим нам производительность не нужна. Но то что было хорошо даже год-два назад, не настолько хорошо сейчас. Впереди - новая версия Windows, впереди планшеты и телефоны по возможностям мало уступающие десктопным компьютерам (и даже использующиеся вместо них с помощью док-станции). Что нам предложит Дельфи? Дельфи будет некроссплатформенной даже в среде Windows. А даже если кроссплатформенность и будет, то через Файрманки, которая, как известно, не позволяет создавать эффективный и удобный нативный интерфейс. Кстати, уже май месяц - что-то я не вижу успешных презентаций компилятора и файрманки под Андроид. Не говоря уже о Windows Phone / Windows RT. В прошлом году, помнится, в это время уже Pulsar можно было бета-тестировать. И то не хватило времени чтобы все баги выпилить! Добавлено Цитата --Ins-- @ У меня в принципе есть задача, может показаться интересной Давай, рассказывай |
|
Сообщ.
#1789
,
|
|
|
|
Цитата [S]mike @ Не подходит? Энамы - очень удачный механизм для карт. Как для рангов и мастей, так и для самих карт. По-моему тут особо нечего замерять. Я могу предложить задачу, где идет обработка достаточно большого объема данных Добавлено Цитата [S]mike @ Давай, рассказывай Попробую сформулировать чтобы было понятно Итак, пусть у нас дана некоторая карта высот - двумерный массив чисел, где каждая точка соотвествует значению высоты. Размер массива может варьироваться, ну скажем обычно в пределах от 100 на 100, до 5000 на 5000. Необходимо разработать контрол, который будет позволять визуализировать эту карту высот и осуществлять по ней навигацию, а именно: 1. Точки карты отображаются различным цветом в зависимости от высоты. Конкретный цвет точки берется из палитры фиксированной длины, где 0-й элемент палитры - это минимальная высота, последний - максимальная, остальные - линейно рассчитываются 2. Контрол может иметь любые размеры, не обязательно равные ширине и высоте массива, картинка должна соотествующим образом масштабироваться а значения точек - интерполироваться. Причем рисоать в битмап и масштабировать уже его - нельзя, это неверно, могу объяснить почему если не понятно 3. Навигация по контролу - выделить левой кнопкой мыши прямоугольник - это зум, нажать правую кнопку и двигать мышью - это перемещение по области данных. 4. При навигации (когда область попадаемая в обзор данных меняется) цвета картинки должны меняться "на лету", так, чтобы минимальной видимой высоте соответсвовал 0-й цвет палитры, а максимальной - последний. Меняться будет потому, что видимый минимум и максимум при навигации изменяются Вот такая вот задача, не знаю понятно ли сформулировал. Но здесь хорошо то, что идет обработка больших объемов данных и можно будет наглядно увидеть скорость этой обработки - плавное перемещение по данным или дерганное - видно на глазок без замеров даже |
|
Сообщ.
#1790
,
|
|
|
|
Цитата --Ins-- @ Вот такая вот задача, не знаю понятно ли сформулировал. Но здесь хорошо то, что идет обработка больших объемов данных и можно будет наглядно увидеть скорость этой обработки - плавное перемещение по данным или дерганное - видно на глазок без замеров даже Как-то крутовато для пузомерки... |
|
Сообщ.
#1791
,
|
|
|
|
Цитата MyNameIsIgor @ Как-то крутовато для пузомерки... Согласен. Также немного напрягает «визуальность», как мы будем замерять ее производительность? «на глазок без замеров», выкладывая ролики на ютюб? =) Лучше тогда определить список операций, их работу и замерять соответствующими инструментами, а вконце вывести в stdout состояние «контрола», чтобы проще было сравнить равенство результатов. |
|
Сообщ.
#1792
,
|
|
|
|
Цитата korvin @ Также немного напрягает «визуальность», как мы будем замерять ее производительность? Можно так. На входе: карта высот, палитра, размеры битмапа на выходе, координаты требуемого участка карты высот. На выходе: битмап. Время получения битмапа можно замерить. |
|
Сообщ.
#1793
,
|
|
|
|
Цитата IL_Agent @ Можно так. На входе: карта высот, палитра, размеры битмапа на выходе, координаты требуемого участка карты высот. На выходе: битмап. Время получения битмапа можно замерить. Можно и так. Но в чем проблема с контролом-то? Меня же тут все уверяют что разработка ГУИ в Delphi сейчас не проще, а даже сложнее чем в других языках. Вот заодно и это проверили бы Добавлено Цитата korvin @ акже немного напрягает «визуальность», как мы будем замерять ее производительность? «на глазок без замеров», выкладывая ролики на ютюб? Взять исполняемый модуль и запустить у себя. А ты как думал? Если каждый будет проверять свой модуль у себя, то победит тот, у кого мощнее комп |
|
Сообщ.
#1794
,
|
|
|
|
Цитата --Ins-- @ Но в чем проблема с контролом-то? Пояснили же. В измерении производительности. "На глазок" - это не наш метод. Ну а мне лично ГУИ просто не интересен |
|
Сообщ.
#1795
,
|
|
|
|
Цитата D_KEY @ "На глазок" - это не наш метод. Я согласен и с вариантом более точных замеров, но контрол хорош тем, что наглядно покажет работу в динамике. Цитата D_KEY @ Ну а мне лично ГУИ просто не интересен Ну раз неинтересен, то уговаривать не буду, хотя здесь речь идет не о кнопкокидательстве, а о разработке класса для визуализации, не вижу что тут может быть неинтересного |
|
Сообщ.
#1796
,
|
|
|
|
Можно точную формулу интерполяции значений высот между узлами?
|
|
Сообщ.
#1797
,
|
|
|
|
Цитата OpenGL @ Можно точную формулу интерполяции значений высот между узлами? Можно. Линейная интерполяция. Для одномерного случая: y' = y1 + (x' - x1)*(y2 - y1) Для двумерного - прикинь с листиком и карандашом, не намного сложнее. Интерполируем сначала по одной оси, потом - по другой |
|
Сообщ.
#1798
,
|
|
|
|
Цитата D_KEY @ Пояснили же. В измерении производительности. "На глазок" - это не наш метод. Ну а мне лично ГУИ просто не интересен ![]() Кроме того, контрол весьма примитивен по сути. Добавлено Цитата --Ins-- @ Взять исполняемый модуль и запустить у себя. А ты как думал? Если каждый будет проверять свой модуль у себя, то победит тот, у кого мощнее комп Ты мне для макоси сделаешь исполняемый модуль? =) |
|
Сообщ.
#1799
,
|
|
|
|
Цитата korvin @ Ты мне для макоси сделаешь исполняемый модуль? А, ну да, печалька, хотя если задаться целью и взять лазарус... Так как тогда тестить? |
|
Сообщ.
#1800
,
|
|
|
|
Цитата --Ins-- @ А, ну да, печалька, хотя если задаться целью и взять лазарус... Так как тогда тестить? Я уже предложил выше. А IL_Agent добавил, что на выход можно посылать битмап, который уже должен отображаться в контроле. Добавлено А, ты про другое. Ну не знаю. Я сразу написал какие языки могу потестить. Делфи среди них не было =) |