Теперь немного понял. Будет неправильно определяться, если размеры объекта будут больше разбиения в 2+ раза. В нашем случае это важно, т.к. есть крохотные места и большие сцены или сектора со свободной рассадкой.
Если я правильно понял Ваш код, работать он будет только для точек в углах квадрата :)
Наведение внутрь объекта не даст результата, т.к. понятно, что не будет существовать таких индексов у Вашего массива. А чтобы они были — нужно разметить так каждую точку на схеме либо также перебирать уже 'boxes', что явно не оптимальнее поиску по дереву. Да и вы потратите кучу памяти, т.к. дублируете объект в массив 4 раза. В общем посыл я не понял, извините.
Деление схемы на квадраты помогает не только искать объект по курсору, но и позволяет вообще не думать об объектах при рендере видимой области: место перебора объектов мы ищем узлы дерева, входящие в зону видимости и показываем все их объекты.
Спасибо за замечание, но если честно, мне кажется удобнее использовать дерево.
Кроме того, в нашей войне за производительность канваса время поиска занимает одно из последних мест, больше всего проблем именно со скоростью отрисовки.
Должна быть в работе, конечно :)
FF почему то на крупном масштабе работает примерно как ie, при приближении становится нормально. Еще не придумал, как это дело ускорить, но я в процессе.
Тут даже вопрос не в том, на чем лучше делать схемы залов, а сколько объектов на этих схемах.
Конечно, если элементов не более 500, проще сделать на дивах или свг. Все будет работать из коробки: клики, ховеры, повороты и прочее.
Но когда схема будет иметь 6к мест и у Вас популярный сервис (т.е. число пользователей условного ie большое), то встанет вопрос: «почему схема открывается 10 секунд?». Вот у нас примерно такая ситуация :)
А решение, описанное в статье, достойно тянет и 20к объектов даже в ie, пример
Совершенно верно. Чтобы работать с объектами любой формы, нужно только доработать определение вхождения точки в объект (при клике и ховере). Передо мной такой задачи не стояло, но доработать недолго.
По поводу HTML схем: думаю, вы не будете спорить, что браузеру намного сложнее отрендерить dom элемент с кучей параметров и событий, чем кучку пикселей на канвасе? :)
Как раз решение перейти на канвас пришло после использования svg и html схем, результат порадовал.
Ну как то истерикой отдает. Получается, «либеральная оппозиция» победила. Понятно, что обидно, когда тебя травят, но для привлечения внимания можно было ограничится сообщением на сайте, без блокирования доступа всем.
Т.е. как сейчас, только с кнопкой «Я не буду травить Элбакян, продолжить пользоваться сервисом»
Если изменить в статье профессию «программист» на любую другую — ничего не изменится. Человеки они такие: есть те, кто делает свою работу относительно хорошо (их мало), и есть остальные.
2. Теплопроводность этого газа в 0,68 раз ниже, чем у воздуха.
это значит, что «теплопроводность аргона» / «теплопроводность воздуха» = 0,68
т.е. вам следует умножатЬ, а не делить
А я про бложики и не говорю :)
Многие хвалят ноду в контексте «убийцы PHP», но я ни разу не видел пример реализации высоконагруженного бекенда с какой то бизнес-логикой.
Фронтенд да, делают и вроде все хорошо. А про бекенд только разговоры и сомнительные сравнения.
Статья носит какой-то негативный характер, «Парень совсем не понимает, что он делает. Тут не поспоришь.»
По мне — все грамотно: замерял, посмотрел на схему, нашел проблему, исправил.
Наведение внутрь объекта не даст результата, т.к. понятно, что не будет существовать таких индексов у Вашего массива. А чтобы они были — нужно разметить так каждую точку на схеме либо также перебирать уже 'boxes', что явно не оптимальнее поиску по дереву. Да и вы потратите кучу памяти, т.к. дублируете объект в массив 4 раза. В общем посыл я не понял, извините.
Спасибо за замечание, но если честно, мне кажется удобнее использовать дерево.
Кроме того, в нашей войне за производительность канваса время поиска занимает одно из последних мест, больше всего проблем именно со скоростью отрисовки.
FF почему то на крупном масштабе работает примерно как ie, при приближении становится нормально. Еще не придумал, как это дело ускорить, но я в процессе.
Конечно, если элементов не более 500, проще сделать на дивах или свг. Все будет работать из коробки: клики, ховеры, повороты и прочее.
Но когда схема будет иметь 6к мест и у Вас популярный сервис (т.е. число пользователей условного ie большое), то встанет вопрос: «почему схема открывается 10 секунд?». Вот у нас примерно такая ситуация :)
А решение, описанное в статье, достойно тянет и 20к объектов даже в ie, пример
По поводу HTML схем: думаю, вы не будете спорить, что браузеру намного сложнее отрендерить dom элемент с кучей параметров и событий, чем кучку пикселей на канвасе? :)
Как раз решение перейти на канвас пришло после использования svg и html схем, результат порадовал.
Т.е. как сейчас, только с кнопкой «Я не буду травить Элбакян, продолжить пользоваться сервисом»
hackerone.com
https://observatory.mozilla.org/analyze.html?host=hackerone.com
это значит, что «теплопроводность аргона» / «теплопроводность воздуха» = 0,68
т.е. вам следует умножатЬ, а не делить
Многие хвалят ноду в контексте «убийцы PHP», но я ни разу не видел пример реализации высоконагруженного бекенда с какой то бизнес-логикой.
Фронтенд да, делают и вроде все хорошо. А про бекенд только разговоры и сомнительные сравнения.
Есть у кого нибудь опыт написания полноценного бекенда на ноде? Я не про чатики говорю :)
По мне — все грамотно: замерял, посмотрел на схему, нашел проблему, исправил.