불행히도 "디지털 마스크"로 어레이를 저장하여 이미지 업데이트 지연 문제에 대처하려는 오늘날의 시도는 성공으로 이어지지 않았습니다. 그렇다고 실패라고 할 수도 없다. 제동의 원인에 대한 최종 결론을 도출하고 이 문제에 대한 글로벌 솔루션을 찾는 것은 불가능했습니다.
완성된 이미지를 메모리에 저장하고 해당 영역으로 작업하는 일반적인 방법에 대해 생각하면서 다양한 옵션을 거쳤습니다. 깊이 반성하면서 좋은 해결책이라고 생각했던 것들은 비실용적인 것으로 판명되었습니다.
제 결론은 다음과 같습니다.
1. 이미지를 배열로 저장하면 배열이 많아야 합니다. 그리고, - 무한정 많이... 즉, 각 리소스에는 고유한 영구 메모리 배열이 필요합니다. 인터페이스 구현에서 캔버스(리소스, 캔버스)의 수는 창의 수보다 몇 배 더 많을 수 있습니다. 연습이 필요합니다.
이유를 설명하겠습니다.
어떤 경우에는 이 방법이 동일한 캔버스에 모든 창 개체를 그리는 것보다 훨씬 더 편리합니다. 예를 들어 - "시야(VEIW BOX)" 요소에서 테이블을 스크롤할 때 이 요소 내부의 별도 캔버스에 테이블 요소를 배치하고 이 캔버스를 전체 개체로 스크롤하는 것이 편리합니다. 스크롤 속도가 더 빠릅니다. 이는 이러한 각 요소가 별도의 캔버스를 가지고 있음을 의미합니다. 그렇지 않으면 메모리에 저장된 전체 창 이미지를 덮어써야 합니다. 확실히 더 오래 걸릴 것입니다.
또한 하나의 캔버스에 모든 창을 그리는 것은 완전히 불편합니다. 그런 다음 어떻게 이동합니까? 차트의 전체 영역에 대해 하나의 "메가" 캔버스를 만들었다고 상상해 보십시오. 우리의 모든 창은 그것에 그려질 것입니다. 캔버스에 창을 그린 후 창을 이동하려고 시도하지만 이 일반적인 "메가" 캔버스의 전체 그림을 다시 작성해야 합니다. 그림이 매우 크고 다시 쓰는 값의 수가 엄청날 것입니다. 그림을 저장하더라도 각 커서 오프셋에서 메모리의 거대한 영역을 다시 작성해야 합니다. 분명히 이것은 비효율적입니다.
2. 이미지를 저장하고 작업하는 방법을 생각하니 "ResourceReadImage()" 함수가 생각났습니다. 이 함수는 리소스를 읽고 디지털 마스크를 배열에 넣습니다. 이는 이미지가 이미 터미널 수준에서 저장되고 이 기능을 사용하여 청구할 수 있기 때문에 이미지를 저장할 필요가 없음을 의미합니다. 이것은 작업을 크게 단순화합니다. 그래서: "ResourceReadImage()"를 사용하여 이미지를 요청하고, 배열로 가져온 다음, 인터페이스의 "이벤트 아래"에 있는 특정 요소와 관련된 배열 값을 변경할 수 있습니다. 제 생각에는 이 접근 방식이 더 매력적으로 보입니다. 그러나 "ResourceReadImage()" 함수를 사용하여 이미지 로 배열을 채우는 데 시간이 얼마나 걸릴까요? 분명히 이것은 캔버스의 영역에 따라 다릅니다. 시각적으로 전혀 눈에 띄지 않을 수 있지만 어쨌든 커서가 특정 캔버스 영역에 있는 동안 한 번만 로드하면 됩니다. 다른 캔버스로 전환할 때 배열을 지우고 다른 캔버스의 이미지를 로드할 수 있습니다.
결론적으로 저는 최종 결정이 없습니다. "ResourceReadImage()" 함수를 실험하고, 이미지 로딩 시간을 측정하고, 배열의 이미지 영역 작업을 위한 시스템을 개발해야 합니다.
그리고 실습에서 알 수 있지만 이미 내 작업의 편의성은 하나의 캔버스에서 정확하게 이루어지며 메인 캔버스를 구성하여 자신의 캔버스에 임시로 테이블 창을 그린 다음 메인 캔버스에서 BitBlt 를 수행할 때 장애물이 없습니다.
왜 "배열이 많아야 합니다. 게다가 무한정 많아야 하는 ..."을 계획했는지 모르겠습니다. 하지만 이것이 막다른 골목이라는 것을 스스로 알 수 있습니다.
아마도 당신은 더 나은 해결책을 찾았을 것입니다. 나는 그것을 기쁘게 볼 것입니다. 가능하면 클릭에 대한 요소의 응답 속도를 명확하게 볼 수 있는 gif를 게시하십시오. gif는 나중에 올리겠습니다. 당신은 내가 말하는 것을 보게 될 것이고, 나는 당신이 말하는 것을 보게 될 것입니다.
Реter Konow : 아마도 당신은 더 나은 해결책을 찾았을 것입니다. 나는 그것을 기쁘게 볼 것입니다. 가능하면 클릭에 대한 요소의 응답 속도를 명확하게 볼 수 있는 gif를 게시하십시오. gif는 나중에 올리겠습니다. 당신은 내가 말하는 것을 보게 될 것이고, 나는 당신이 말하는 것을 보게 될 것입니다.
영상은 안찍었지만 예시를 올려봅니다. 빠르게 스케치했다.
600개의 드롭다운 목록이 있습니다.
마우스 이동 - 각 이벤트 및 색상 변경과 함께 일반 CCanvas가 다시 그려집니다. 그 상호 작용을 얻으십시오.
비트맵 속성에서 최종 크기(1500x600픽셀)를 볼 수 있습니다(800x500 및 250ms 지연과 비교). 이는 900,000포인트와 동일하며 모든 것이 즉시 다시 그려집니다. 몇 초의 이야기가 있을 수 없습니다.
각 목록은 먼저 자체 캔버스에 고유한 크기로 그려지고(경계를 넘지 않도록) 그런 다음 일반 목록에만 적용됩니다. 즉, 각 마우스 이벤트에 대해 600개의 ResourceCreate 호출 이 있습니다. 즉, 반응 속도에서 알 수 있듯이 표시할 프레임과 만화가 충분합니다.
MT 개발자는 브레이크 없이 만족스러운 도구를 제공했습니다(ResourceCreate 비트맵을 말하는 것입니다)
마우스 이동 - 각 이벤트 및 색상 변경과 함께 일반 CCanvas가 다시 그려집니다. 그 상호 작용을 얻으십시오.
비트맵 속성에서 최종 크기(1500x600픽셀)를 볼 수 있습니다(800x500 및 250ms 지연과 비교). 이는 900,000포인트와 동일하며 모든 것이 즉시 다시 그려집니다. 몇 초의 이야기가 있을 수 없습니다.
각 목록은 먼저 자체 캔버스에 고유한 크기로 그려지고(경계를 넘지 않도록) 그런 다음 일반 목록에만 적용됩니다. 즉, 각 마우스 이벤트에 대해 600개의 ResourceCreate 호출 이 있습니다. 즉, 반응 속도에서 알 수 있듯이 표시할 프레임과 만화가 충분합니다.
MT 개발자는 브레이크 없이 만족스러운 도구를 제공했습니다(ResourceCreate 비트맵을 말하는 것입니다)
글쎄, 이것은 당신의 말을 확인하기에 충분합니다 ... 그러나 나는 어제의 질문을 다시 할 것입니다. 이미지가 저장 되었습니까?
어제 말씀드린대로 - 한번 생성된 이미지를 저장하고 그 안의 특정 영역만 변경하고 즉시 ResourceCreate()로 보내면 지연이 발생하지 않습니다. 귀하의 캔버스 작업 방법은 아직 저에게 익숙하지 않습니다. 나는 아직도 당신이 이 결과를 정확히 어떻게 달성했는지 모릅니다.
또 다른 질문이 있습니다. CCanvas 클래스를 사용하여 위의 예제를 만들 때 이 솔루션을 구현하는 원리를 설명할 수 있습니까?
아마도 비트 연산이 이미지 처리에 사용됩니다. 나는 아직 그들을 다루지 않았습니다.
추신 하지만 저는 스스로 비밀을 푸는 것을 좋아합니다...) 어쨌든 이 문제는 해결하겠습니다.
불행히도 "디지털 마스크"로 어레이를 저장하여 이미지 업데이트 지연 문제에 대처하려는 오늘날의 시도는 성공으로 이어지지 않았습니다. 그렇다고 실패라고 할 수도 없다. 제동의 원인에 대한 최종 결론을 도출하고 이 문제에 대한 글로벌 솔루션을 찾는 것은 불가능했습니다.
완성된 이미지를 메모리에 저장하고 해당 영역으로 작업하는 일반적인 방법에 대해 생각하면서 다양한 옵션을 거쳤습니다. 깊이 반성하면서 좋은 해결책이라고 생각했던 것들은 비실용적인 것으로 판명되었습니다.
제 결론은 다음과 같습니다.
1. 이미지를 배열로 저장하면 배열이 많아야 합니다. 그리고, - 무한정 많이... 즉, 각 리소스에는 고유한 영구 메모리 배열이 필요합니다. 인터페이스 구현에서 캔버스(리소스, 캔버스)의 수는 창의 수보다 몇 배 더 많을 수 있습니다. 연습이 필요합니다.
이유를 설명하겠습니다.
어떤 경우에는 이 방법이 동일한 캔버스에 모든 창 개체를 그리는 것보다 훨씬 더 편리합니다. 예를 들어 - "시야(VEIW BOX)" 요소에서 테이블을 스크롤할 때 이 요소 내부의 별도 캔버스에 테이블 요소를 배치하고 이 캔버스를 전체 개체로 스크롤하는 것이 편리합니다. 스크롤 속도가 더 빠릅니다. 이는 이러한 각 요소가 별도의 캔버스를 가지고 있음을 의미합니다. 그렇지 않으면 메모리에 저장된 전체 창 이미지를 덮어써야 합니다. 확실히 더 오래 걸릴 것입니다.
또한 하나의 캔버스에 모든 창을 그리는 것은 완전히 불편합니다. 그런 다음 어떻게 이동합니까? 차트의 전체 영역에 대해 하나의 "메가" 캔버스를 만들었다고 상상해 보십시오. 우리의 모든 창은 그것에 그려질 것입니다. 캔버스에 창을 그린 후 창을 이동하려고 시도하지만 이 일반적인 "메가" 캔버스의 전체 그림을 다시 작성해야 합니다. 그림이 매우 크고 다시 쓰는 값의 수가 엄청날 것입니다. 그림을 저장하더라도 각 커서 오프셋에서 메모리의 거대한 영역을 다시 작성해야 합니다. 분명히 이것은 비효율적입니다.
2. 이미지를 저장하고 작업하는 방법을 생각하니 "ResourceReadImage()" 함수가 생각났습니다. 이 함수는 리소스를 읽고 디지털 마스크를 배열에 넣습니다. 이는 이미지가 이미 터미널 수준에서 저장되고 이 기능을 사용하여 청구할 수 있기 때문에 이미지를 저장할 필요가 없음을 의미합니다. 이것은 작업을 크게 단순화합니다. 그래서: "ResourceReadImage()"를 사용하여 이미지를 요청하고, 배열로 가져온 다음, 인터페이스의 "이벤트 아래"에 있는 특정 요소와 관련된 배열 값을 변경할 수 있습니다. 제 생각에는 이 접근 방식이 더 매력적으로 보입니다. 그러나 "ResourceReadImage()" 함수를 사용하여 이미지 로 배열을 채우는 데 시간이 얼마나 걸릴까요? 분명히 이것은 캔버스의 영역에 따라 다릅니다. 시각적으로 전혀 눈에 띄지 않을 수 있지만 어쨌든 커서가 특정 캔버스 영역에 있는 동안 한 번만 로드하면 됩니다. 다른 캔버스로 전환할 때 배열을 지우고 다른 캔버스의 이미지를 로드할 수 있습니다.
결론적으로 저는 최종 결정이 없습니다. "ResourceReadImage()" 함수를 실험하고, 이미지 로딩 시간을 측정하고, 배열의 이미지 영역 작업을 위한 시스템을 개발해야 합니다.
오늘은 그게 다야.Реter Konow :
인터페이스 구현에서 캔버스(리소스, 캔버스)의 수는 창의 수보다 몇 배 더 많을 수 있습니다. 연습이 필요합니다.
당신의 연습은 그것을 요구합니다.
그러나 자신의 실습에서 알 수 있듯이 이러한 구현은 속도와 편의성 면에서 결함이 있습니다.
그리고 실습에서 알 수 있지만 이미 내 작업의 편의성은 하나의 캔버스에서 정확하게 이루어지며 메인 캔버스를 구성하여 자신의 캔버스에 임시로 테이블 창을 그린 다음 메인 캔버스에서 BitBlt 를 수행할 때 장애물이 없습니다.
왜 "배열이 많아야 합니다. 게다가 무한정 많아야 하는 ..."을 계획했는지 모르겠습니다. 하지만 이것이 막다른 골목이라는 것을 스스로 알 수 있습니다.
당신의 연습은 그것을 요구합니다.
그러나 자신의 연습이 보여주듯이 이러한 구현은 속도와 편의성 면에서 결함이 있습니다.
그리고 실습에서 알 수 있지만 이미 내 작업의 편의성은 하나의 캔버스에서 정확하게 이루어지며 메인 캔버스를 구성하여 자신의 캔버스에 임시로 테이블 창을 그린 다음 메인 캔버스에서 BitBlt 를 수행할 때 장애물이 없습니다.
왜 "배열이 많아야 합니다. 게다가 무한정 많아야 하는 ..."을 계획했는지 모르겠습니다. 하지만 이것이 막다른 골목이라는 것을 스스로 알 수 있습니다.
아마도 당신은 더 나은 해결책을 찾았을 것입니다. 나는 그것을 기쁘게 볼 것입니다. 가능하면 클릭에 대한 요소의 응답 속도를 명확하게 볼 수 있는 gif를 게시하십시오. gif는 나중에 올리겠습니다. 당신은 내가 말하는 것을 보게 될 것이고, 나는 당신이 말하는 것을 보게 될 것입니다.
영상은 안찍었지만 예시를 올려봅니다. 빠르게 스케치했다.
600개의 드롭다운 목록이 있습니다.
마우스 이동 - 각 이벤트 및 색상 변경과 함께 일반 CCanvas가 다시 그려집니다. 그 상호 작용을 얻으십시오.
비트맵 속성에서 최종 크기(1500x600픽셀)를 볼 수 있습니다(800x500 및 250ms 지연과 비교). 이는 900,000포인트와 동일하며 모든 것이 즉시 다시 그려집니다. 몇 초의 이야기가 있을 수 없습니다.
각 목록은 먼저 자체 캔버스에 고유한 크기로 그려지고(경계를 넘지 않도록) 그런 다음 일반 목록에만 적용됩니다. 즉, 각 마우스 이벤트에 대해 600개의 ResourceCreate 호출 이 있습니다.
즉, 반응 속도에서 알 수 있듯이 표시할 프레임과 만화가 충분합니다.
MT 개발자는 브레이크 없이 만족스러운 도구를 제공했습니다(ResourceCreate 비트맵을 말하는 것입니다)
영상은 안찍었지만 예시를 올려봅니다. 빠르게 스케치했다.
600개의 드롭다운 목록이 있습니다.
마우스 이동 - 각 이벤트 및 색상 변경과 함께 일반 CCanvas가 다시 그려집니다. 그 상호 작용을 얻으십시오.
비트맵 속성에서 최종 크기(1500x600픽셀)를 볼 수 있습니다(800x500 및 250ms 지연과 비교). 이는 900,000포인트와 동일하며 모든 것이 즉시 다시 그려집니다. 몇 초의 이야기가 있을 수 없습니다.
각 목록은 먼저 자체 캔버스에 고유한 크기로 그려지고(경계를 넘지 않도록) 그런 다음 일반 목록에만 적용됩니다. 즉, 각 마우스 이벤트에 대해 600개의 ResourceCreate 호출 이 있습니다.
즉, 반응 속도에서 알 수 있듯이 표시할 프레임과 만화가 충분합니다.
MT 개발자는 브레이크 없이 만족스러운 도구를 제공했습니다(ResourceCreate 비트맵을 말하는 것입니다)
글쎄, 이것은 당신의 말을 확인하기에 충분합니다 ... 그러나 나는 어제의 질문을 다시 할 것입니다. 이미지가 저장 되었습니까?
어제 말씀드린대로 - 한번 생성된 이미지를 저장하고 그 안의 특정 영역만 변경하고 즉시 ResourceCreate()로 보내면 지연이 발생하지 않습니다. 귀하의 캔버스 작업 방법은 아직 저에게 익숙하지 않습니다. 나는 아직도 당신이 이 결과를 정확히 어떻게 달성했는지 모릅니다.
또 다른 질문이 있습니다. CCanvas 클래스를 사용하여 위의 예제를 만들 때 이 솔루션을 구현하는 원리를 설명할 수 있습니까?
아마도 비트 연산이 이미지 처리에 사용됩니다. 나는 아직 그들을 다루지 않았습니다.
추신 하지만 저는 스스로 비밀을 푸는 것을 좋아합니다...) 어쨌든 이 문제는 해결하겠습니다.
CCanvas 클래스를 사용하여 위의 예를 만들면 이 솔루션이 어떻게 구현되는지 설명할 수 있습니까?
원칙 선형 - 컨트롤 목록을 살펴보고 캔버스의 올바른 위치에 각 컨트롤을 그립니다.
CCanvas 함수만 컨트롤을 그리는 데 사용됩니다. 혼자서는 아무 것도 하지 않았습니다.
예를 들어 축소된 형식의 목록은 두 개의 요소로 그려집니다. 이 예에서는 버튼(다른 스타일에서는 다르게)
캔버스 함수가 호출됩니다.
FillRectangle // 배경 채우기
직사각형 // 주변 프레임
FontSet // 글꼴 설정
TextOut // 텍스트 출력
아마도 비트 연산이 이미지 처리에 사용됩니다.
아니요.
이미지 저장?
예, CCanvas에 있는 배열에서
한 번 생성된 이미지를 저장하고 그 안의 특정 영역만 변경하고 즉시 ResourceCreate()로 보내면 지연이 없습니다.
확실히 그런 방식은 아닙니다.
내 예에서는 전체 배열이 다시 그려집니다. 배열이 지워지고 렌더링할 때마다 전체 캔버스가 다시 채워집니다. 그런 다음 ResourceCreate가 호출 됩니다.
내 예에서는 전체 배열이 다시 그려집니다. 배열이 지워지고 렌더링할 때마다 전체 캔버스가 다시 채워집니다. 그런 다음 ResourceCreate가 호출 됩니다.
자세한 답변 감사합니다.
이상하지만 나도 같은 것이 있다. 전체 창의 이미지는 각 인터페이스 이벤트에서 완전히 다시 생성됩니다. 이것은 이 절차가 완료될 때 ResourceCreate 로 전송되는 로컬 1차원 배열로 구축됩니다.
왜 느려지는지 모르겠습니다... 내일은 창 크기와 요소의 응답 속도 사이의 관계를 보여주는 gif를 게시하겠습니다.
이 모든 것이 매우 이상합니다...
자세한 답변 감사합니다.
이상하지만 나도 같은 것이 있다. 전체 창의 이미지는 각 인터페이스 이벤트에서 완전히 다시 생성됩니다. 이것은 이 절차가 완료될 때 ResourceCreate 로 전송되는 로컬 1차원 배열로 구축됩니다.
왜 느려지는지 모르겠습니다... 내일은 창 크기와 요소의 응답 속도 사이의 관계를 보여줄 gif를 게시하겠습니다.
이 모든 것이 매우 이상합니다...
어렵지 않다면 작업관리자에서 CPU 사용량으로 gif 애니메이션을 만들어보세요. 또는 sergeev 가 했던 것처럼 컴파일된 파일 을 게시하는 것이 더 쉽습니다. 직접 테스트할 수 있도록 합니다.
좋아요, CPU 로딩으로 영상을 만들겠습니다. 그러나 컴파일된 파일에 대해서는 아직 업로드하지 않겠습니다.
벌레들에겐 너무 창피할 뿐...)))
내가 그것들을 고칠 때, 나는 그것들을 게시할 것을 약속한다.
좋아요, CPU 로딩으로 영상을 만들겠습니다. 그러나 컴파일된 파일에 대해서는 아직 업로드하지 않겠습니다.
벌레들에겐 너무 창피할 뿐...)))
내가 그것들을 고칠 때, 나는 그것들을 게시할 것을 약속한다.