Вопросы по LCL
Модератор: Модераторы
>>Задать после align'а ещё и top... Скажем
не помогает.
>>Кстати, я бы на месте компилятора на 2 и 3 строчку ругнулся ^_^
по причине?
Добавлено спустя 2 часа 38 минут 25 секунд:
чето ситуация совсем мне не понятна:
сверху у меня TPageControl, снизу TPanel. по середине соответственно надо воткнуть сплитер
На нижнем TPanel лежит TMemo, в который выводятся текст паралельно с логом (хочу видеть последние сообщения), еще до показа всей формы. в линуксе в этом случае мне никак не удалось расположить сплитер как надо, он всегда липнет неправильно. Стоит выключить вывод в мемо до показа формы, всё начинает работать нормально
Добавлено спустя 1 час 18 минут 58 секунд:
под линуксом метод repaint без Application.ProcessMessages не работает?
Добавлено спустя 15 часов 36 минут 3 секунды:
Чем отличается рантайм добавление контролов на видимую форму и еще не показаную форму (в AfterConstruction)? у меня получается в этих 2х случаях разные результаты при использовании align. в первом случае контролы выстраиваются в обратном порядке относительно добавления, во втором в прямом.
не помогает.
>>Кстати, я бы на месте компилятора на 2 и 3 строчку ругнулся ^_^
по причине?
Добавлено спустя 2 часа 38 минут 25 секунд:
чето ситуация совсем мне не понятна:
сверху у меня TPageControl, снизу TPanel. по середине соответственно надо воткнуть сплитер
На нижнем TPanel лежит TMemo, в который выводятся текст паралельно с логом (хочу видеть последние сообщения), еще до показа всей формы. в линуксе в этом случае мне никак не удалось расположить сплитер как надо, он всегда липнет неправильно. Стоит выключить вывод в мемо до показа формы, всё начинает работать нормально
Добавлено спустя 1 час 18 минут 58 секунд:
под линуксом метод repaint без Application.ProcessMessages не работает?
Добавлено спустя 15 часов 36 минут 3 секунды:
Чем отличается рантайм добавление контролов на видимую форму и еще не показаную форму (в AfterConstruction)? у меня получается в этих 2х случаях разные результаты при использовании align. в первом случае контролы выстраиваются в обратном порядке относительно добавления, во втором в прямом.
Переделал инициализацию OpenGL на лазарный TOpenGLControl, теперь всё рисуется и под виндой и под линуксом. но под линуксом както странно...
С виду вроде не тормозит и замер времени отрисовки выдает теже цифры что и вин версия (правда мерию с помощью now(), наверно это неверно).
как в линуксе происходит обработка мыши? такое впечатление что мышиные сообщения не успевают обрабатываться и мышка плавает.
можно ли в обработчике мышки (onMouseMove) посмотреть есть еще в очереди сообщения от мыши (если конечно под линуксом есть аналог виндовой очереди сообщений) и не выполнять тяжелые операции, оставив их до последнего сообщения?
Добавлено спустя 23 часа 46 минут 8 секунд:
Голова совсем не соображает:
1)
таким образом я получу время в милисикундах ушедшее на деланье гадости или в DeltaTime будет палец в небе?
2)
Отличаются ли результаты работы компилятора под лин и под вин скоростью выполенния? мне пункт 1 говорит что не отличается, а по факту перебор в цикле 20000 объектов тормозит обработку движенья мыши
3)
прошу посмотреть тормозят ли движенья мышью под linux+gnome http://download.shamangrad.net/zcad/CAD.tar.bz2 (10Мб)
запустить zcad_fpc, выбрать пункт меню **Debug**\Загрузить пример ОПС, подождать пока чтонибудь нарисуется и поелозить мышкой
С виду вроде не тормозит и замер времени отрисовки выдает теже цифры что и вин версия (правда мерию с помощью now(), наверно это неверно).
как в линуксе происходит обработка мыши? такое впечатление что мышиные сообщения не успевают обрабатываться и мышка плавает.
можно ли в обработчике мышки (onMouseMove) посмотреть есть еще в очереди сообщения от мыши (если конечно под линуксом есть аналог виндовой очереди сообщений) и не выполнять тяжелые операции, оставив их до последнего сообщения?
Добавлено спустя 23 часа 46 минут 8 секунд:
Голова совсем не соображает:
1)
Код: Выделить всё
PrevTime:=now();
...........делаем гадость..............
DeltaTime:=round((now()-PrevTime)*10e7)таким образом я получу время в милисикундах ушедшее на деланье гадости или в DeltaTime будет палец в небе?
2)
Отличаются ли результаты работы компилятора под лин и под вин скоростью выполенния? мне пункт 1 говорит что не отличается, а по факту перебор в цикле 20000 объектов тормозит обработку движенья мыши
3)
прошу посмотреть тормозят ли движенья мышью под linux+gnome http://download.shamangrad.net/zcad/CAD.tar.bz2 (10Мб)
запустить zcad_fpc, выбрать пункт меню **Debug**\Загрузить пример ОПС, подождать пока чтонибудь нарисуется и поелозить мышкой
таким образом я получу время в милисикундах ушедшее на деланье гадости или в DeltaTime будет палец в небе?
Не знаю в чём получится время (голова не работает), но оно, скорее всего, будет больше, чем то, которое потрачено на выполнение действия.
Не знаю в чём получится время (голова не работает), но оно, скорее всего, будет больше, чем то, которое потрачено на выполнение действия.
Пусть больше, главное не меньше.
Получается процедура длиной в 3-5 милисекунд всё тормозит - процедура выбора объекта под мышью. В винде всё работает отдично((
Помню раньше, при компиляции ядра была настройка preemptible kernel или что-то подобное...
Может влиять? Вообще, причин много может быть.
Может влиять? Вообще, причин много может быть.
Вообще, причин много может быть.
я не вижу ни одной. Видимо в линуксе нельзя рисовать так как под виндой.
У меня из onMouseMove вызывается перерисовка opengl окна, не repaint/invalidate, а glBegin-.....-glEnd на текущий контекст.
лог при быстрых движениях мышью показывает следующее:
под windows
onMouseMove обрабатываются непрерывно, как только закончилось предидущая обработка сразу начинается следующая, без пауз (в пределах точности now). Внутри onMouseMove вызываются процедуры нахождения объектов под мышью (getonmouseobject) и перерисовки окна(draw).
getonmouseobject длится в среднем - 0 мс
draw - 16мс
соответственно весь onMouseMove длится - 16мс
под ubuntu 10.04
между onMouseMove наблюдаются паузы 2мс..4мс
getonmouseobject - 3мс
draw - 0мс..1мс
видимо под линуксом опенгл рисует из отдельного потока (т.к. фактически не занимает времени) и onMouseMove убегает от него вперед. а glFinish почемуто не помогает.
Добавлено спустя 14 часов 38 минут 43 секунды:
Всё оказалось просто...
Хитрый билли добавляет WM_MOUSEMOVE в очередь если приложение не занято, если занято правит уже добавленое сообщение.
В гноме (в X?) честно посылается каждый пиксел проеханый мышкой в отдельном сообщении.
Теперь всё работает как надо
опять парит мозг реализация tmemo для GTK2.
1 как правильно сделать автоcкролл при добавлении текста?
2 как перерисовать когда приложение занято? без application.processmessages tmemo не перерисовывается, а например tprogressbar прекрасно перерисовывается
1 как правильно сделать автоcкролл при добавлении текста?
2 как перерисовать когда приложение занято? без application.processmessages tmemo не перерисовывается, а например tprogressbar прекрасно перерисовывается
как можно в onKeyDown формы узнать где была нажата клавиша, т.е. какой контрол в данный момент имеет фокус ввода? думал это будет sender, но нет, sender всегда сама форма
- Nik
- энтузиаст
- Сообщения: 573
- Зарегистрирован: 03.02.2006 23:08:09
- Откуда: Киров
- Контактная информация:
zub писал(а):как можно в onKeyDown формы узнать где была нажата клавиша, т.е. какой контрол в данный момент имеет фокус ввода? думал это будет sender, но нет, sender всегда сама форма
Проверить ActiveControl.Name?
zub
Посмотрите функцию ControlAtPos.
Добавлено спустя 1 минуту 14 секунд:
пс Бррр сори неправильно прочитал вопрос
Посмотрите функцию ControlAtPos.
Добавлено спустя 1 минуту 14 секунд:
пс Бррр сори неправильно прочитал вопрос
Nik
>>Проверить ActiveControl
спасибо, оно самое!
>>Проверить ActiveControl
спасибо, оно самое!
С уровнем оптимизации 0, 1 - программа работает.
С 2, 3 - крашится на казалось бы безобидном месте - создании пункта меню, внутри LCL в lclclasses.pp
я так понимаю гдето раньше портится куча. есть какиенибудь способы без бубна найти где?
Добавлено спустя 1 час 48 минут 20 секунд:
есть ли какаялибо директива условной компиляции сигнализирующая о подключении heaptrc?
чтоб работала конструкция вида
при компиляции с -gh
С 2, 3 - крашится на казалось бы безобидном месте - создании пункта меню, внутри LCL в lclclasses.pp
Код: Выделить всё
constructor TLCLComponent.Create(TheOwner: TComponent);
begin
inherited Create(TheOwner); <---------------------------------тут падаем
{$IFDEF DebugLCLComponents}
//DebugLn('TLCLComponent.Create ',DbgSName(Self));
DebugLCLComponents.MarkCreated(Self,DbgSName(Self));
{$ENDIF}
end;я так понимаю гдето раньше портится куча. есть какиенибудь способы без бубна найти где?
Добавлено спустя 1 час 48 минут 20 секунд:
есть ли какаялибо директива условной компиляции сигнализирующая о подключении heaptrc?
чтоб работала конструкция вида
Код: Выделить всё
{$IFDEF ??????}SetHeapTraceOutput('log/memory-heaptrace.txt');{$ENDIF} при компиляции с -gh
zub насколько знаю директива не создаётся. Хотя было бы не плохо...
>>насколько знаю директива не создаётся
обидно, такая удобная галка в иде остается не у дел((
обидно, такая удобная галка в иде остается не у дел((
эх... продолжаю недогонять как в линуксе работать с мышью.... в наследнике TOpenGLControl перекрыт
в нем для отлова двойного щелчка средней кнопки присутствует конструкция
Почемуто в зависимости от времени работы Pre_MBMouseDblClk сообщение двойного щелчка может прийти 2 раза. Т.е. если в программу загружен большой файл и Pre_MBMouseDblClk работает сравнительно медленно, она вызывается 2 раза. Внутри Pre_MBMouseDblClk "анимированная" opengl отрисовка. под виндой естественно всё работает нормально.
Код: Выделить всё
procedure MouseDown(Button: TMouseButton; Shift: TShiftState;X, Y: Integer);override;в нем для отлова двойного щелчка средней кнопки присутствует конструкция
Код: Выделить всё
if ssDouble in shift then
begin
if ssMiddle in shift then
begin
Pre_MBMouseDblClk(Button,Shift,X, Y);
{exclude(shift,ssdouble);
exclude(shift,ssMiddle);}
exit;
end;
end;Почемуто в зависимости от времени работы Pre_MBMouseDblClk сообщение двойного щелчка может прийти 2 раза. Т.е. если в программу загружен большой файл и Pre_MBMouseDblClk работает сравнительно медленно, она вызывается 2 раза. Внутри Pre_MBMouseDblClk "анимированная" opengl отрисовка. под виндой естественно всё работает нормально.
