Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Pcb123, DesignSpark, Pulsonix, DipTrace — САПРы, но что-то серьёзное в них разрабатывать не будешь, разве что из мазохизма Тут кто-то из камрадов выравнивал сигналы вручную.

Не все САПРы конечно требовательные к ресурсам, но в целом рисовалка там далеко не самая сложная часть. С рисовалкой справлялось железо времен раннего вындоуса, соответсвенно, справится и нынешний жээс. Сейчас в канвасе можно отрисовывать столько же примитивов как в дотнете времён нулевых в System.Drawing. А вот впихнуть объектную модель тех времен мягко говоря не выйдет, даже с учетом разницы 32-64 бита.

Скажем, в дотнет времен конца нулевых можно было запихнуть условные 100 млн (я трохи округлил, что бы проще считать было) объектов всех-всех типов, в 32х битной адресации это давало около 1.2гб адресного пространства(из расхода 4байт object sync, 4 байта lvtbl и 4 байта данных) и уже тут начинались проблемы со сборкой мусора из за фрагментации. С некоторыми ухищрениями, что бы вместиться в ограничение в 2гб адресного пространства, можно было искусственно посклеивать объекты, сделать 10млн вместо 100, увеличив средний размер объекта. Тогда можно было выюзать память в районе 1.6-1.8гб. Дальше — всё.
Переход на 64х битную адресацию давал около 4гб расход памяти.
Если всё то же самое запихнуть в жээс 1 в 1, то нам понадобится в 5-10 раз больше памяти, а это 20-40гб. Собственно, это только полезные объекты, а сверх этого немалое количество памяти ест сам рантайм v8, браузер и другие приложения, и сама операционка. И штука в том, что эти 20-40мб в сапр могут понадобиться все и сразу, условно — пусканули мелкий алгоритм, который собирает данные, а он прокачивает через себя почти всю модель.
Т.е. по памяти браузер пока не готов справиться с большими приложениями.

P>>Офисный редактор не ровня CAD, и близко. В редакторе довольно куцая модель данных. Даже IDE существенно отстаёт от CAD.

SVZ>Заглядывал внутрь вордовского документа?
SVZ>Количество объектов в документе на пару десятков страниц вполне сравнимо с двухслойной печатной платой.

Я не только заглядывал туда и сюда, но и разрабатывал САПРы первые 11 лет. Средненький САПР это примерно от 10мб плотного кода, из которого 80% это та самая объектная модель-сторадж и операции над ней. Все остальное — импорт, экспорт, UI, рисовалка, скриптинг, репорты, настроки и тд.

P>>OnShape это далеко не первый CAD на веб технологиях

SVZ>Да, их за последние лет 5 наплодилось как собак нерезаных. Ожидаемо.

Я думаю, что это долговременный тренд.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Pcb123, DesignSpark, Pulsonix, DipTrace — САПРы, но что-то серьёзное в них разрабатывать не будешь, разве что из мазохизма Тут кто-то из камрадов выравнивал сигналы вручную.

Не все САПРы конечно требовательные к ресурсам, но в целом рисовалка там далеко не самая сложная часть. С рисовалкой справлялось железо времен раннего вындоуса, соответсвенно, справится и нынешний жээс. Сейчас в канвасе можно отрисовывать столько же примитивов как в дотнете времён нулевых в System.Drawing. А вот впихнуть объектную модель тех времен мягко говоря не выйдет, даже с учетом разницы 32-64 бита.

Скажем, в дотнет времен конца нулевых можно было запихнуть условные 100 млн (я трохи округлил, что бы проще считать было) объектов всех-всех типов, в 32х битной адресации это давало около 1.2гб адресного пространства(из расхода 4байт object sync, 4 байта lvtbl и 4 байта данных) и уже тут начинались проблемы со сборкой мусора из за фрагментации. С некоторыми ухищрениями, что бы вместиться в ограничение в 2гб адресного пространства, можно было искусственно посклеивать объекты, сделать 10млн вместо 100, увеличив средний размер объекта. Тогда можно было выюзать память в районе 1.6-1.8гб. Дальше — всё.
Переход на 64х битную адресацию давал около 4гб расход памяти.
Если всё то же самое запихнуть в жээс 1 в 1, то нам понадобится в 5-10 раз больше памяти, а это 20-40гб. Собственно, это только полезные объекты, а сверх этого немалое количество памяти ест сам рантайм v8, браузер и другие приложения, и сама операционка. И штука в том, что эти 20-40мб в сапр могут понадобиться все и сразу, условно — пусканули мелкий алгоритм, который собирает данные, а он прокачивает через себя почти всю модель.
Т.е. по памяти браузер пока не готов справиться с большими приложениями.

P>>Офисный редактор не ровня CAD, и близко. В редакторе довольно куцая модель данных. Даже IDE существенно отстаёт от CAD.

SVZ>Заглядывал внутрь вордовского документа?
SVZ>Количество объектов в документе на пару десятков страниц вполне сравнимо с двухслойной печатной платой.

Я не только заглядывал туда и сюда, но и разрабатывал САПРы первые 11 лет. Средненький САПР это примерно от 10мб плотного кода, из которого 80% это та самая объектная модель-сторадж и операции над ней. Все остальное — импорт, экспорт, UI, рисовалка, скриптинг, репорты, настроки и тд.

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

P>>OnShape это далеко не первый CAD на веб технологиях

SVZ>Да, их за последние лет 5 наплодилось как собак нерезаных. Ожидаемо.

Я думаю, что это долговременный тренд.