1. 제가 원래 이야기했던 문제라면 어떤 경우에는 알고리즘 솔루션으로 충분할 수 있습니다.
2. 말씀하신 문제라면 몇 가지 함수로는 충분하지 않습니다. 모든 레이어가 배열에 저장되는 방식이 필요합니다. 각 레이어는 그 아래 레이어에 그려진 내용을 고려하여 그려야 합니다. 또한 CCanvas 클래스의 모든 메서드를 수정해야 합니다. 각 픽셀의 색상은 투명도를 고려하여 그 아래 픽셀과 혼합되어야 합니다. 그러면 아티팩트(간격, 들쭉날쭉한 가장자리 등)가 생기지 않습니다. 올바르게 수행하면 흐림으로 반투명을 구현할 수 있습니다. 이 모든 것은 단일 캔버스에서 구현하기에 충분히 쉽습니다. 그러나 여러 개의 캔버스를 사용하는 경우에는 구현하기가 훨씬 더 어렵습니다.
그리고 하나의 캔버스에서 모든 것이 작동하도록 그래픽 라이브러리를 다시 작성할 준비가 되어 있지 않습니다.
흥미롭긴 하지만 시간이 얼마나 걸릴지 알기 때문에 지금 당장은 그런 도전을 할 수 없습니다. 지금은 예전만큼 시간이 많지 않거든요.
저는 실제로 여러 개의 캔버스를 사용합니다(보통 4개 이하).
항상 황금률은 존재합니다. 한 가지 극단적인 방법은 하나의 캔버스에 모든 정적 요소와 모든 동적 요소를 그리는 것이고, 다른 극단적인 방법은 모든 개체를 별도의 캔버스에 그리는 것입니다.
투명도가있는 두 개의 캔버스가 서로 겹치는 경우 여전히 CPU (Win10-11 GPU 일 수도 있지만 여전히 CPU라고 생각합니다)가 각 픽셀을 균일 한 (투명도가 0이 아닌) 배경까지 혼합한다는 사실을 잊지 않는 것이 중요합니다.
여기서 우리는 성능을 향상시키기 위해 캔버스 또는 그 일부를 캐싱하는 관행을 JS에서 빌릴 수 있습니다.
앤티 앨리어싱 원에 관해서는 이미 반경이 ~ 5 픽셀 미만인 원에 이상적인 (성능 측면에서) 이러한 원의 변형을 게시했습니다. 이 함수는 iDot()이라고 불렸고 3DStars 코드에 있었던 것 같습니다. 매우 원시적이고 짧습니다(약 10줄의 코드). 반경이 큰 원의 경우 성능 측면에서 최적과는 거리가 멀다. 더 큰 반경의 경우 고성능 함수는 이미 100줄이 넘는 코드입니다.
네, 수년간 캔버스에서 뇌의 새로운 신경 연결을 구축한 끝에 이제 캔버스에서 어떤 수준의 라이브러리도 만들 수 있습니다. 시간과 동기만 있다면 말이죠.
1. 제가 원래 이야기했던 문제라면 어떤 경우에는 알고리즘 솔루션으로 충분할 수 있습니다.
2. 당신이 언급 한 것이라면 몇 가지 기능으로는 충분하지 않습니다. 모든 레이어가 배열에 저장되는 체계가 필요합니다. 각 레이어는 그 아래 레이어에 그려진 내용을 고려하여 그려야합니다. 또한 CCanvas 클래스의 모든 메서드를 수정해야 합니다. 각 픽셀의 색상은 투명도를 고려하여 그 아래 픽셀과 혼합되어야 합니다. 그러면 아티팩트(간격, 들쭉날쭉한 가장자리 등)가 생기지 않습니다. 올바르게 수행하면 흐림으로 반투명을 구현할 수 있습니다. 이 모든 것은 단일 캔버스에서 구현하기에 충분히 쉽습니다. 그러나 여러 개의 캔버스를 사용하는 경우에는 구현하기가 훨씬 더 어렵습니다.
저는 스무딩 알고리즘에 대해서만 이야기하고 있다고 생각했습니다. 투명한 캔버스를 서로 겹치는 것과는 무관하게 말이죠. 하지만... 겹쳐서 사용하면 새로운 문제가 반드시 나타납니다. 그는 오랫동안 모든 신경 연결을 가지고 있으며 그의 뇌는 아마도 캔버스의 모든 가능한 문제를 고려하여 이미 스스로 생각하고있을 것입니다).
스무딩 알고리즘에 대해서만 이야기한 줄 알았는데요. 투명한 캔버스를 겹쳐서 겹치는 것에 대한 언급은 없었습니다. 하지만... 겹쳐서 사용하면 새로운 문제가 분명히 나타날 것입니다. 그래서 제가 Nikolay를 언급 한 이유입니다. 그는 오랫동안 모든 신경 연결을 가지고 있으며 그의 뇌는 아마도 캔버스의 모든 가능한 문제를 고려하여 이미 스스로 생각하고있을 것입니다).
아르템, 이것은 새로운 신경 연결이 필요한 사소한 작업이 아닙니다. 예를 들어 SVG에는 viewBox와 같은 개념이 있습니다. 나는 이미 그것이 어떻게 작동하는지에 대한 많은 비디오를 보았고, 많은 문서를 읽고, 많은 코드를 작성했지만 여전히 때때로 당황합니다. 여러 번 모든 것을 알아낸 것 같았지만 여전히 필요한 신경 연결이 없습니다.
모든 스무딩 방법은 선 불투명도에 따라 크게 달라집니다. 약 50% 불투명도에서는 모든 것이 에일리어싱되지 않고 아티팩트가 생깁니다.
이제 완전히 불투명한 선에서도 아티팩트가 발생합니다.
우리는 부드러움을 잃지 않고 가장자리가 매끄러운 완전 불투명 원을 그리는 것에 대해 이야기하고 있었습니다(Wu의 알고리즘 사용).
이를 위해서는 부드러운 가장자리로 채우는 특별한 방법이 필요합니다.
이제 완전히 불투명한 선에도 아티팩트가 있습니다.
우의 알고리즘을 사용하여 매끄러운 가장자리를 가진 완전히 불투명한 원을 매끄러움의 손실 없이 그리는 것이었습니다.
이를 위해서는 부드러운 가장자리로 채우는 특별한 방법이 필요합니다.
직접 할 수 없다는 것을 이해했나요?
혼자서는 할 수 없다는 걸 알았나요?
왜 안 될까요? 도전해 보세요! )
말씀하신 사례도 해결할 수 있습니다:
트레이딩, 자동매매 시스템 및 트레이딩 전략 테스트 포럼
"시각화하라! R의 플롯과 유사한 MQL5의 그래픽 라이브러리" 기사에 대한 토론
아르톰 트리쉬킨, 2023.07.31 12:39 AM
모든 스무딩 방법은 선 불투명도에 따라 크게 달라집니다. 약 50%의 불투명도에서는 모든 것이 매끄럽지 않고 아티팩트가 생깁니다.
즉, 완전히 투명한 캔버스(CCanvas)에 그리는 것은 하단 레이어(차트 및 기타 개체)를 고려하여 수행할 수 있으며 아티팩트가 없습니다.
그러나 그것은 다소 목발이 있고 번거로워 보입니다. 또한 성능에 얼마나 영향을 미칠지도 불분명합니다. 그래도 터미널 개발자가이 버그를 수정하기를 바랍니다.
왜 안 될까요? 한번 시도해 보세요! )
말씀하신 사례도 해결할 수 있습니다:
즉, 완전히 투명한 캔버스(CCanvas)에서 하단 레이어(차트 및 기타 개체)를 고려하여 렌더링할 수 있으며 아티팩트 없이 렌더링할 수 있습니다.
그러나 다소 번거롭고 번거로워 보입니다. 또한 성능에 얼마나 영향을 미칠지도 불분명합니다. 그래도 터미널 개발자가이 버그를 수정하기를 바랍니다.
나는 그러한 작업 (개발자가 아니라 포럼 회원이 아니라면)을 Nikolai @Nikolai Semko에게 보내 해결책을 찾을 것입니다.)
그런 작업(개발자가 아니라 포럼 회원이라면)은 Nikolai @Nikolai Semko에게 보내서 해결하도록 하겠습니다.)
그는 단 하나의 캔버스로 작업합니다.
그리고 모든 것이 하나의 캔버스에서 작동하도록 그래픽 라이브러리를 다시 작성할 준비가되지 않았습니다.
흥미롭기는 하지만 시간이 얼마나 걸릴지 알기 때문에 지금 당장은 그런 도전을 할 수 없습니다. 지금은 예전만큼 시간이 많지 않아요.
하나의 캔버스에서만 작동합니다.
그리고 하나의 캔버스에서 모든 것이 작동하도록 그래픽 라이브러리를 다시 작성할 준비가 되어 있지 않습니다.
흥미롭긴 하지만 시간이 얼마나 걸릴지 알기 때문에 지금 당장은 그런 도전을 할 수 없습니다. 지금은 예전만큼 시간이 많지 않아요.
알고리즘이잖아요. 하나의 캔버스에서든 여러 캔버스에서든 어떤 차이가 있나요?
알고리즘이죠. 캔버스 하나에 넣든 여러 개에 넣든 어떤 차이가 있을까요?
우리는 두 가지 문제를 논의했습니다:
1. 제가 원래 이야기했던 문제라면 어떤 경우에는 알고리즘 솔루션으로 충분할 수 있습니다.
2. 말씀하신 문제라면 몇 가지 함수로는 충분하지 않습니다. 모든 레이어가 배열에 저장되는 방식이 필요합니다. 각 레이어는 그 아래 레이어에 그려진 내용을 고려하여 그려야 합니다. 또한 CCanvas 클래스의 모든 메서드를 수정해야 합니다. 각 픽셀의 색상은 투명도를 고려하여 그 아래 픽셀과 혼합되어야 합니다. 그러면 아티팩트(간격, 들쭉날쭉한 가장자리 등)가 생기지 않습니다. 올바르게 수행하면 흐림으로 반투명을 구현할 수 있습니다. 이 모든 것은 단일 캔버스에서 구현하기에 충분히 쉽습니다. 그러나 여러 개의 캔버스를 사용하는 경우에는 구현하기가 훨씬 더 어렵습니다.
하나의 캔버스에서만 작동합니다.
그리고 하나의 캔버스에서 모든 것이 작동하도록 그래픽 라이브러리를 다시 작성할 준비가 되어 있지 않습니다.
흥미롭긴 하지만 시간이 얼마나 걸릴지 알기 때문에 지금 당장은 그런 도전을 할 수 없습니다. 지금은 예전만큼 시간이 많지 않거든요.
두 가지 과제에 대해 논의했습니다:
1. 제가 원래 이야기했던 문제라면 어떤 경우에는 알고리즘 솔루션으로 충분할 수 있습니다.
2. 당신이 언급 한 것이라면 몇 가지 기능으로는 충분하지 않습니다. 모든 레이어가 배열에 저장되는 체계가 필요합니다. 각 레이어는 그 아래 레이어에 그려진 내용을 고려하여 그려야합니다. 또한 CCanvas 클래스의 모든 메서드를 수정해야 합니다. 각 픽셀의 색상은 투명도를 고려하여 그 아래 픽셀과 혼합되어야 합니다. 그러면 아티팩트(간격, 들쭉날쭉한 가장자리 등)가 생기지 않습니다. 올바르게 수행하면 흐림으로 반투명을 구현할 수 있습니다. 이 모든 것은 단일 캔버스에서 구현하기에 충분히 쉽습니다. 그러나 여러 개의 캔버스를 사용하는 경우에는 구현하기가 훨씬 더 어렵습니다.
저는 스무딩 알고리즘에 대해서만 이야기하고 있다고 생각했습니다. 투명한 캔버스를 서로 겹치는 것과는 무관하게 말이죠. 하지만... 겹쳐서 사용하면 새로운 문제가 반드시 나타납니다. 그는 오랫동안 모든 신경 연결을 가지고 있으며 그의 뇌는 아마도 캔버스의 모든 가능한 문제를 고려하여 이미 스스로 생각하고있을 것입니다).
스무딩 알고리즘에 대해서만 이야기한 줄 알았는데요. 투명한 캔버스를 겹쳐서 겹치는 것에 대한 언급은 없었습니다. 하지만... 겹쳐서 사용하면 새로운 문제가 분명히 나타날 것입니다. 그래서 제가 Nikolay를 언급 한 이유입니다. 그는 오랫동안 모든 신경 연결을 가지고 있으며 그의 뇌는 아마도 캔버스의 모든 가능한 문제를 고려하여 이미 스스로 생각하고있을 것입니다).
아르템, 이것은 새로운 신경 연결이 필요한 사소한 작업이 아닙니다. 예를 들어 SVG에는 viewBox와 같은 개념이 있습니다. 나는 이미 그것이 어떻게 작동하는지에 대한 많은 비디오를 보았고, 많은 문서를 읽고, 많은 코드를 작성했지만 여전히 때때로 당황합니다. 여러 번 모든 것을 알아낸 것 같았지만 여전히 필요한 신경 연결이 없습니다.