솔루션을 개발해야 합니다 . 내 창은 복잡한 MT 개체 - 캔버스로 구성됩니다. 이미지를 먼저 개별적으로 축소한 다음 하나로 결합해야 합니다. 그런 알고리즘이 필요합니다. 즉, 개별적으로 있다고 가정하지만 축소 사진을 결합하는 것은 아직 아닙니다.
먼저, 당연히 해야 합니다. 즉, 약간 일관된 모양을 갖습니다. 옛날에 그들은 말했다 - 그만, 졸업 .. 글쎄, 좋아, 엔진은 멈출 수 없다 ;-) 이것이 영원한 작가의 버전이라고 가정 할 것입니다 ..
C#과의 그러한 춤이 사라졌기 때문에 "지구의 나머지 부분보다 앞서" - OpenGL을 보십시오. 그리고 그것들을 "캔버스"에 그립니다(적당한 장소에서는 그렇게 부르지 않지만 컨텍스트입니다). 엄청나게 빠르며 원하는 것을 오버레이, 크기 조정, 회전, 왜곡할 수 있습니다.
먼저, 당연히 해야 합니다. 즉, 약간 일관된 모양을 갖습니다. 옛날에 그들은 말했다 - 그만, 졸업 .. 글쎄, 좋아, 엔진은 멈출 수 없다 ;-) 이것이 영원한 작가의 버전이라고 가정 할 것입니다 ..
C#과의 그러한 춤이 사라졌기 때문에 "지구의 나머지 부분보다 앞서" - OpenGL을 보십시오. 그리고 그것들을 "캔버스"에 그립니다(적당한 장소에서는 그렇게 부르지 않지만 컨텍스트입니다). 엄청나게 빠르며 원하는 것을 오버레이, 크기 조정, 회전, 왜곡할 수 있습니다.
물론 자신을 위해 쓴다면 말이다. 그러나 모든 파슬리는 시장에 있습니다.
OpenGL 또는 DirectX로 작업한 적이 있습니까? 비디오 카드 리소스를 사용합니까?
ZY 어리석은 질문이지만. 물론 예.
개발자가 OpenGL이 아닌 OpenCL을 망친 이유를 이해할 수 없습니까? 하기가 더 쉽기 때문일 것입니다.
ZYY OpenCL을 존경합니다. 이 기술은 컴퓨팅에 더 중점을 두고 있으므로 OpenGL을 선택하지 않은 이유를 이해할 수 있습니다.
솔루션을 개발해야 합니다. 내 창은 복잡한 MT 개체 - 캔버스로 구성됩니다. 이미지를 먼저 개별적으로 축소한 다음 하나로 결합해야 합니다. 그런 알고리즘이 필요합니다. 즉, 개별적으로 있다고 가정 해 봅시다. 그러나 축소 된 사진을 결합하기 위해서는 아직 없습니다.
물체의 상대 좌표 변화 계산. 그들에게도 출발점이 있습니다. X와 Y에서. 일반 캔버스 창의 너비와 높이의 전체 크기를 기준으로 다시 계산합니다.
물체의 상대 좌표 변화 계산. 그들에게도 출발점이 있습니다. X와 Y에서. 일반 캔버스 창의 너비와 높이의 전체 크기를 기준으로 다시 계산합니다.
아이디어를 얻었습니다. 니콜라이가 거절한다면 내가 해볼게. 고맙습니다.
솔루션을 개발해야 합니다 . 내 창은 복잡한 MT 개체 - 캔버스로 구성됩니다. 이미지를 먼저 개별적으로 축소한 다음 하나로 결합해야 합니다. 그런 알고리즘이 필요합니다. 즉, 개별적으로 있다고 가정하지만 축소 사진을 결합하는 것은 아직 아닙니다.
먼저, 당연히 해야 합니다. 즉, 약간 일관된 모양을 갖습니다. 옛날에 그들은 말했다 - 그만, 졸업 .. 글쎄, 좋아, 엔진은 멈출 수 없다 ;-) 이것이 영원한 작가의 버전이라고 가정 할 것입니다 ..
C#과의 그러한 춤이 사라졌기 때문에 "지구의 나머지 부분보다 앞서" - OpenGL을 보십시오. 그리고 그것들을 "캔버스"에 그립니다(적당한 장소에서는 그렇게 부르지 않지만 컨텍스트입니다). 엄청나게 빠르며 원하는 것을 오버레이, 크기 조정, 회전, 왜곡할 수 있습니다.
물체의 상대 좌표 변화 계산. 그들에게도 출발점이 있습니다. X와 Y에서. 일반 캔버스 창의 너비와 높이의 전체 크기를 기준으로 다시 계산합니다.
먼저, 당연히 해야 합니다. 즉, 약간 일관된 모양을 갖습니다. 옛날에 그들은 말했다 - 그만, 졸업 .. 글쎄, 좋아, 엔진은 멈출 수 없다 ;-) 이것이 영원한 작가의 버전이라고 가정 할 것입니다 ..
C#과의 그러한 춤이 사라졌기 때문에 "지구의 나머지 부분보다 앞서" - OpenGL을 보십시오. 그리고 그것들을 "캔버스"에 그립니다(적당한 장소에서는 그렇게 부르지 않지만 컨텍스트입니다). 엄청나게 빠르며 원하는 것을 오버레이, 크기 조정, 회전, 왜곡할 수 있습니다.
이 벡터 스케일링 방법은 래스터 스케일링에 시각적으로 매우 손실됩니다. 그리고 텍스트는 어떻습니까? 글꼴 크기 가 불균형적으로 증가합니다.
가장 먼저 떠오른 것은. 아마도 3D Studio MAX에서 벡터 그래픽을 사용한 오랜 작업이 영향을 미칠 것입니다. 저는 그렇게 생각하는 데 익숙합니다. 예, 물론 모든 것이 이중으로 이루어지며 Photoshop의 비트맵 크기 조정보다 시각적으로 훨씬 뛰어납니다.
이 벡터 스케일링 방법은 래스터 스케일링에 시각적으로 매우 손실됩니다. 그리고 텍스트는 어떻습니까? 글꼴 크기 가 불균형적으로 증가합니다.
그리고 여기서 SMS가 떠올랐습니다. 필요한 양식 창의 비트맵 이미지를 가져온 다음 단일 비트맵 개체로 크기를 조정합니다.
그리고 여기서 SMS가 떠올랐습니다. 필요한 양식 창의 비트맵 이미지를 가져온 다음 단일 비트맵 개체로 크기를 조정합니다.
글쎄, 다른 방법은? 그것이 Peter가 원했던 것이라고 생각합니다.
다음은 width_bmp x height_bmp 치수의 BMP[] 배열에 있는 기성 래스터 스케일링 기능입니다.