DWD писал(а):Ладно, не парьтесь. Буду по старинке пока.

Мне сегодня принесли раритет, )) сейчас с ним вожусь.
В общем в ХР в команде "Start" нет параметра "affinity", так что с ядрами только через доп утилиты.
А приоритет есть. Просто надо убрать affinity из строки.

%systemroot%\system32\cmd.exe /c start "flp.exe" /high "D:\FLProg-1.10.1_Portable\FLProg.exe"

и все работает.

rw6cm, спасибо, этот заработал.
Только ни чего не меняется...

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

С Вашим вариантом ярлыка получается тоже самое, что и с обычным - ядро одно, а приоритет низкий и его всё равно нужно менять вручную.

DWD, Странно... Так не должно быть, хотя от винды можно ожидать чего угодно))
Сейчас железка под рукой древняя, одно ядро, целик 1,8 не могу с ядрами поиграться
Подвернется что нить по свежее, если не забуду обязательно попробую.

rw6cm, ну только если делать будет нечего... 
Спасибо.

Вариант с приоритетами не выход из положения. Не стоит в это углубляться. Надо в самой программе что-то менять.
Во время построения схемы проекта я так понимаю происходит автоматическая проверка правильности соединений блоков. А судя по тормозам это происходит при каждом шаге курсора мыши. Мне кажется, что именно проверка соединений с приоритетом реального времени и создает проблему.
В самой программе есть кнопка проверки проекта. Что если рассмотреть вариант добавить кнопку - ПРОВЕРКА СОЕДИНЕНИЙ например. Может ли это решить проблему с тормозами?
Допустим мы будем строить наш проект вводить данные, параметры, а после нажимаем кнопку "проверка соединений" и происходит чудо - проверяются висящие концы, проверка соединений по типам данных и в итоге СООБЩЕНИЕ: соединения либо корректные, либо нет, и в последнем случае выводятся ошибки, допущенные при формировании проекта.
В программировании я не силен, но руководствуясь логикой должно сработать.
Автор программы как вы думаете может ли это решить проблему с тормозами программы?

Позвольте и мне задать вопрос.
при переносе схемки платы в другой проект или открытие платы  нет соединения элементов (обычно входные) после как передергниш  элемент соединение востонавливаетса. Добавлено (26.01.2016, 20:53)
---------------------------------------------
В версии 10.3 этот баг пропал!

на ноутбуке стоял режим экономия энергии-жутко тормозил. выставил режим сбалансированный все летает

Версия 2.4.0, тормозит безбожно, нормально работать начинает только в приоритете "Реального времени". Реально грустно смотреть когда ткнув в блок он выделяется секунд через 5-7, это нечто.... Я делал себе программку для некоторых расчётов (в Делфи), так тоже сначала стремился к проверке всего и вся при каждом изменении любого значения, в итоге достиг результата что при изменении любой циферки программа считала секунд по 10-15... в итоге переделывал чтоб только по глобальным изменениям считала.
Не нужно чтоб при каждом движении мышки она прогоняла весь  алгоритм платы на правильность, только по ключевым действиям пусть проверяет, протянул соединение, проверка, двинул блок, нет проверки. 
Сам я только начал осваивать Ардуину, в поисках вариантов программирования натолкнулся на  flprog, очень с трудом даётся программирование в чистом виде, кое как немного Делфи освоил, но с С+ и подобными грустно всё, думал вот и среда под мои задумки, ан не всё так просто оказалось, с такими тормозами к середине реализации задуманного проекта можно будет сходить чайку попить пока соседний блок выделит...
Сделайте что нибудь с этим вопросом, совсем грустно однако.

FlintFD, приоритет реального времени и задать процессу соответствие, чтобы работал на одном ядре. И ещё у меня синезубая мышь лагает временами, при этом тачпад на ноуте без проблем работает. Может имеет смысл проводную мышь попробовать?

Так я и говорю, что приемлемо нормально работает только в приоритете реального времени и задана работа на одном ядре. В остальных комбинациях жуткий тормоз. Вот только процесс реального времени может плохо сказаться на работе системы в целом, с непредвиденными последствиями. У меня комп Архикад без проблем ворочает, немаленькие проекты, а тут... Но ведь такой способ программирования мне даже очень понравился, и хотелось бы даже остаться в этой программе (начал врубаться). Но небольшой экспериментальный проект выдал такие тормоза.
У меня проводная мышь, беспроводные не приживаются почему то, быстро дохнут .

Я стараюсь по мере возможности оптимизировать отрисовку. Вы ещё не работали на старых версиях - это было намного хуже. Все таки я не проффесиональный программист, а любитель(((. Я примерно знаю как ещё можно оптимизировать скорость работы, но это надо лезть в дебри моей среды программирования. Я пока не нашол точку где отлавливается событие перемещения мыши и преобразуется в команду на перерисовку. Где то глубине контроллера (у меня используется архитектура MVC). Как доберусь - думаю получится ускорить отрисовку раз в 10-20 и отвязаться от типа мыши.

Тут не отрисовка мне кажется, а проверка условий и целостности проекта по каждому чиху проходит. Что и тормозит в итоге всё и вся, всё что не на С++ и подобном, очень уж тормозят комп. Когда перемещается мышь то заметно что при пересечении соединительной линии эта линия мигает (выделяется) на какое то время в таком состоянии подвисает и выделяется следующая часть проекта, и пока мыщь движется, то всё на своём пути вот так подмаргивает (что очень заметно при тормозах), т.е происходит проверка проекта с частотой опроса мыши и плюс каждое выделение, т.е. выполняется условие "если есть изменение или выделение то провести проверку проекта". Программа движение мыши считает изменением (ну оно в принципе так и есть и так и должно быть), для отрисовки блоков и линий программа всегда должна знать положение курсора, а если ввести условие дополнительно "и нажата кнопка" только тогда проверять проект. Но это при перемещении блоков тоже будет работать, тогда ещё условие добавить "и внесены изменения в данные проекта". Ну программист из меня так себе, даже практически никак, но свою программу я так и побеждал, пришлось переписывать очень много, разбивать на блоки и вводить условия проверки только при совпадении нескольких условий, иначе вот также вынужденные перекуры наблюдать стал.

Я вот мыслю аналогично - во всем виновата мышь, но добавив дополнительные условия наверно добавятся и тормоза.
При движении курсора по рабочей области на каждом шаге происходят вычисления положения курсора над объектами (блоками, линиями, надписями и т.д.). Это видно по красной подсветке объектов при движении курсора. Получается при каждом сдвиге курсора на 1 пиксель вычисляется над каким же объектом находится курсор, и попавший в заданную область объект подсвечивается. Допустим мышь сдвинулась на 500 пикселей вверх и на 500 в сторону, и в рабочей области находится 100 объектов - это же сколько раз надо проверить условия, сколько операций сравнения и вычислений нужно обработать!?
А что если убрать подсветку объектов во время движения курсора мыши и включать ее только когда курсор зафиксировался на какое-то время (10мс допустим), т.е. пока мышь бегает на рабочем пространстве меняется только положение курсора, а как только курсор остановился или сработали кнопки мыши тут-то можно отрисовкой и вычислениями заняться. А проверку проекта производить исключительно при внесении каких либо изменений в рабочей области (соединение, перемещение, удаление, добавление объектов). Реально ли это воплотить или в силу недостаточных моих знаний в программировании я не правильно мыслю?
Может ли влиять разрешение самой мыши DPI на работу программы?

Я так понял что прогу глючит на 64 разрядной системе. На работе слабее комп но 32 разрядная W7, дома мощнее комп но 64 разрядная W7. Дома пользоваться программой невозможно, каждое действие требует 5-10 секунд.

Дома W7 х64, core i5, без внешней видюхи - FLProg летает.
На работе W7 х32, Pentium E5300, видюха nVidia - FLProg полный тормоз.

У меня Flp подтормаживала раньше на больших проектах и переодически валилась. Заметно уменьшились такие косяки после уменьшения пункта UNDO (откат действия) до 0, рискованно , но я почаше сохрагняю проект вручную.

Boroda писал(а):Дома W7 х64, core i5, без внешней видюхи - FLProg летает.На работе W7 х32, Pentium E5300, видюха nVidia - FLProg полный тормоз.

Вы счастливый человек, у всех наоборот почемуто (почитайте форум).
Поделитесь счастьем со всеми как добиться чтобы нормально работала FlProg на 64 разрядной системе.
Заранее спасибо.


на этой системе тормозит.


а тут летает. Где смеяться?

fagot, либо смеяться над мышью, либо над видеокартой nVidia. Ведь в рабочем компе видюха встроенная Intel HD скорее всего, а в домашнем Вашем внешняя и скорее всего nVidia. Меня давно уже терзают сомнения по поводу видеокарт. На АМДшных и Интеловских видюхах все нормально работает.

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

Что помогает для ускорения работы:
1) делать экран как можно уже.
2) торможение в том числе и из-за винчестера. Помогает установка портативной версии FLPROG на виртуальный диск в оперативке.

Надеюсь, что автору удастся со временем совладать с этой проблемой - пока это сдерживает в написании сложных плат Flprog и больших программ.