QT действительно такая немощьная?

1) плата за "buffer overflow safety"
2) смотри kernel/qpixmap_x11.cpp
думаю в Qt4 - это должно быть заложено на уровне QPaintera

прочитай книжку про QT на opennet.ru и не будешь задавать идиотских вопросов.

>1) Хочешь нарисовать на окне одну букву - отправь её в QString. Два динамических >выделения памяти, два освобождения. Да уж... Так вот с чего kvim так бессовестно >тормозит?

бред, opera например летает.

1) да, это видимо системная недоработка; в большинстве случаев память освобождать не надо, всё равно по завершению работы всё вернется на круги своя. К тому-же периодичное выделение-освобождение объектов фиксированного объема вызвает в ГГц диапазоне хорошо различимый шум , модулированный на частоте системной шины, так что это прямая наводка хакерам и некоторым,местами компетентным, органам. Да и разработка замедляется из-за необходимости думать, где-же ставить требуемый delete,
что в больших коллективах ведет к неоправданным потерям рабочего времени. Что хорошо видно, на так удачно приведённом Вами примере - kvim, Вы только посмотрите на Changelog - когда этот ацтойный проект начат. А если поставить рядом нормальную станцию радиоразведки, то будет совершенно очевидно, что использовать kvim - значит напрямую сливать инфу врагам, кои не дремлют и конкурентам. 
2) Еще одна недоработка..видимо никогда не будет исправленна, они там в trolltech думают, что раз сделали explicit sharing, то так сразу всё и покатило..нефига - без mit-shm не видать им щастья и удачи.
*) да, да упустили.. там есть еще и какие-то сигналы и слоты, что вообще ни в какие ворота не лезет, это уже не C++ и еще не Smalltalk, непонятность какая-то. Дёрнули идею оттуда, навернули её сюда, запустили пеар и вот они бабки-то. А пионеры-то повелись на рекламку ! И начали клепать K* и Q* проекты. действительно исключительно just-for-fun..Кстати поведись не только дети, но и вроде-как серьёзные дядьки/компании, но им видимо набашляли на яхту-другую..

Но это должно, обязательно должно пройти ! И будет рулить mono (уже говорят где-то поруливает) и придёт торжество VB и других..наверное уже сейчас в недрах интел делается аппаратный trash-collector, а некоторые прочие компании создают сверхрульный язык и платформу C-бакс, и делать там вообще ничего не нужно будет, исключительно голосовое управление !

Так что светлое будущее - ждёт с нетерпением !



P.S. это был не флейм, это был вопрос - а Вы вообще чё-нить на C/C++ делали ?

1. Объекты QString являются "Implicitly Shared", читайте доки

я поражён услышанным. вы комиком нигде не работали ?

>>смотри kernel/qpixmap_x11.cpp

отрисовке с помощью XPutImage предшевстыует некислое преобразование QImage => QPixmap. Это очень медленно.

>>Два динамических выделения памяти, два освобождения.

Вас волнует выделение памяти ? Давайте займёмся глобальными вопросами - а как вы вообще собрались хранить строку в памяти ? Без выделения что-ли ? :) Более того, выделения больших обьёмов памяти (если её хватит для malloc) вообще занимает микросекунды.

>>mit-shm Image - отсутствует напрочь

Да, это плохо. Но можно всегда открыть изображение с помощью QImage::load и самому отрисовать его. Получить несжатые данные можно с помощью QImage::convertDepth() + QImage::bits().

Вот здесь http://ksquirrel.sourceforge.net/DLOAD/qpixbuf.tar.bz2 я нашёл пример. Оригинальный пример был где-то в списках рассылки QT (qt-interest). Там есть класс для отрисовки массива данных на ваджете.

Кстати для толкового отображения изображений надо сварганить что-то типа OpenGL'вских матриц и вьюпортов - чтобы некая либа полностью взяла бы на себя отрисовку изображений с помощью MIT-SHM, отображению видимых/невидимых участков и т.д.

>>Я что-то упустил? ТакоЕ впечатление, что делается она just-for-fun

У вас только одна серьёзная причина, и то она быстро решается сторонними способами. QT имеет кучу преимуществ (кроссплатформенных !!), которые не дают программисту тратить время на изобретение графических компонентов (типа таблиц, иерархических деревьев и т.д.) и утилит (типа QStringList::split()).

kvim в KDE - уникальный элемент. он выполнен как внепроцессный (out-of-process) компонент, и более того, основан на родном vim, и связь kvim'а c Qt условна (уж тем более QString в этой связи не участвует). Есть ещё только один аналогично выполненный компонент - kmozilla, в потрохах которого - GtkMozEmbed. Интересующиеся могут подробнее почитать по ключевым словам "XPart KDE"

2devinull: Qt - один из лучших образцов API на C++. Если хочешь гибкого выделения памяти - взгляни на Gtk--: его авторы сами говорят, что просто ступили ("were just stupid"), когда включили в библиотеку возможность создавать элементы на стеке, в куче с удалением программистом и в куче с автоматическим удалением. Хотели даже переписать всё заново

Не, ну ви таки поццените, через что приходится пройти бедному еврею, дабы написать хороший C++ API!!! А мойшет, это проблевма языка C++, что такие грабли у нём на каждом шагу?

Я вообщето не пытался её (Qt) обругать. Я имел ввиду немного другое. Почему нельзя сделать что-то вроде

QPainter::drawText( int x, int y, const QChar* psz, int charcnt );

И почему нет mit-shm Image? В X такая фича есть, в оффтопике - CreateDIBSection()...

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

2butterfly Респект, хоть кто-то к топику отнёсся конструктивно.

>>придётся всю Qt с ног на голову перевернуть и в результате получится совершенно непереносимая вещь

зачем ? непереносимая получится, только если использовать непереносимые вещи (как MIT-SHM), которые являются ОЧЕНЬ узкоспециализированными. Для обычных задач - создать интерфейс, открыть/прочитать файл, нарисовать, связаться с мусклем, скачать файл с инета и т.д. QT прекрасно (быстро, переносимо) справляется.

Вы хотите сказать, что на какой-то платформе нельзя найти аналог? Имеете ввиду кого-то из популярных? Под оффтопик - есть такая, под X - есть, на framebuffer - ну просто аминь...

Хотя с alpha каналом и правда все плохо, в X он почемуто реализован не то чтобы очень удачно, и что - то его это не спешат исправлять. Но без него именно библиотека высокого уровня и могла бы представлять _переносимые_ средства.

Спасибо за ссылку.

Далеко не на каждом X будет MIT-SHM работать.

ещё раз могу сказать, что именно такая узкоспециализированная задача должна решаться отдельной либой типа OpenGL. С MMX оптимизацией, MST-SHM И прочими вкусностями. Вот то, что такой либы нет - да, проблема.

Для QT и такой отрисовки хватит.

ну вообще в qt входит binding к OpenGL.

советую почитать книжку на opennet, там есть примеры работы как с двухмерной так и с трехмерной графикой.

Зато MIT-SHM есть в Gtk+ >:) даже с shm-pixmap'ами. И хорошо работает

Привет butterfly,
сушествует довольно мнoго libs:
http://antigrain.com/
http://www.cairographics.org/introduction
http://developer.gnome.org/arch/imaging/gdkpixbuf.html
последняя содержит MMX optimization.
я и сам (не без помощи Саши Васько - afterstep WM author)
занимаюсь этим последнее время
http://root.cern.ch/root/htmldoc/TASImage.html
вставление MIT-SHM - то, чем я занимаюсь,
как раз, в настояший момент ...

++
http://www.libsdl.org/index.php !!!

хех. Я OpenGL'ем + QT занимался два года, не нужно мне книжек с оупеннета :)

Речь не о том. А том, как при отсутствии видео акселерации в виде нативных драйверов _очень_ быстро отрендерить пиксмап ? в Иксах это делается с помощью MIT-SHM. Драйверы есть не у всех, и они иногда не очень хорошие.

Ни одна из этих либ (кроме TAS, пока не видел) не занимается тем, о чём идёт речь ;)

>>http://developer.gnome.org/arch/imaging/gdkpixbuf.html

См. ссылку, что я давал выше о qpixbuf (это не совсем то, но имеет pixops, выдранный из gdk-pixbuf, и MIT-SHM отрисовку).

А что это за TAS ? Судя по наследованию это что, из Билдера ? :)

если в Иксы поддерживают нужную технологию, почему бы не вызывать Иксовые функции напрямую?
тот же XDrawText, например.

речь шла изначально о mit-shm. читайте сначала. Тест отрисовывать это не проблема, проблема - отрисовать 1024x768 изображение за <= 10 мс. Попробуйте это сделать без акселерации и mit-shm.

>1) Хочешь нарисовать на окне одну букву - отправь её в QString. Два динамических выделения памяти, два освобождения. Да уж... Так вот с чего kvim так бессовестно тормозит?


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


>2) mit-shm Image - отсутствует напрочь. А как тогда графический редактор например сворганить?


Насколько я помню, от mit-shm отказались в пользу более производительного механизма. Смотреть исходники.


>Я что-то упустил? Такоt впечатление, что делается она just-for-fun. А её такая толпа народу истользует...

боюсь, лучшего еще не придумали.