да нет, не любое. Изображения с другого сервера нарисуются на канве, но toBlob после этого уже не сработает. Там тот же принцип - если нельзя скачать аяксом, то и нельзя забрать с канвы.
Anonymous Penguin, нет, реверсить не придется, я ведь предлагаю сделать цикл в обратном направлении. unshift в цикле нежелателен - приводит к О(N^2) на ровном месте, это может сказаться на скорости, если итераций много
А что за либа? Почти наверняка она это делает через canvas, у которого кроме toDataUrl есть ещё toBlob. Я к тому, что стоит присмотреться к документации либы, возможно там есть сохранение в блоб вместо base64.
Владимир Коротенко, эти тонкости тоже могут сильно зависеть от фигур. Если будет какой-то переиспользуемый код, то его лучше вынести в утилсы. Ну или как крайний вариант, для каких-то фигур сделать общие промежуточные подклассы.
Понадобятся подклассы для рисования каждого типа фигур (разумеется, если автору вопроса надо напроектировать православное ООП, а не скатиться в switch/case).
Причем экземпляр класса-рисовальщика по хорошему должен получить свою конкретную фигуру как параметр в конструктор, потому как нельзя передавать ему в render эту фигуру как ссылку на базовый NewShape.
На самом верху будет массив или словарь с фабриками, которые создают как фигуру, так и рисовальщика. Причем, если рисовальщик создается не вместе с фигурой, то не обойтись без ручного приведения NewShape к конкретному типу...
лучше использовать готовый модуль, потому что задача по факту чуть более геморная, чем кажется на первый взгляд: надо проследить, чтобы курсор не улетал в конец или начало, после редактирования в середине строки, редактирования выделенного фрагмента, а так же вставки из буфера при этих условиях. Там возникает много различных кейсов.
кстати, можно прямо сразу по формуле, без цикла, но может потеряться точность.
и подозреваю (но нельзя сказать наверняка), что можно посчитать за O(ln N), аналогично фаст-даблингу для фибоначчей