-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix(#183) 강의 참여시 곧바로 발표자의 화이트보드가 보이도록 개선 #184
Fix(#183) 강의 참여시 곧바로 발표자의 화이트보드가 보이도록 개선 #184
Conversation
로컬 서버로 주소 변경 및 디버기용 버튼을 추가했습니다.
canvas의 JSON 데이터를 실시간으로 생성하는 프로토 타입 함수를 구현했습니다.
fabric canvas에서 강의자가 줌인 한 정도와 마우스로 움직인 정도를 저장하고 불러오게 했습니다.
소켓 연결 실패할 경우 에러 toast를 띄우고, 서버 연결이 완료된 경우에만 안내 toast를 띄우고 타이머를 작동시키도록 했습니다.
onframe에 renderAll 메서드로 계속해서 화면을 갱신하여 참여자가 입장과 함께 화면을 바로 보기 좋도록 개선해보았습니다.
디버깅 용도의 버튼을 삭제하고, 미디어 서버의 주소를 원래대로 변경했습니다.
✅ Deploy Preview for boarlog ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
오류 해결 과정에서 사용하기위해 import한 내용을 제거했습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
주말인데 고생 많으셨습니다!! ㅠㅠㅠ 결국 해결하셨군요... 대단하십니다 :)
if (!fabricCanvasRef) return; | ||
fabricCanvasRef.renderAll(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
여기가 핵심이군요! 리렌더링이 반복되는데 생각보다 성능 차이가 없다는 점이 신기하네요 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
오호 신기하네요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
깊은 고민을 통한 문제 해결 과정이 너무 흥미롭습니다.
고생하셨습니다.
작업 개요
close #183
강의 참여 시 발표자의 화면 로딩 시간이 길어지거나 아예 보이지 않는 이슈
작업 사항
231203-2.mp4
로컬에서 미디어 서버를 실행시켜 확인한 결과입니다.
발표자가 화이트보드를 건드리지 않아도 참여자 페이지에서 바로 화면이 보입니다.
고민한 점들(필수 X)
노션 개발일지에 아래 내용을 정리했습니다.
https://weak-sugar-603.notion.site/eaa2870a3d194b06a2773605e63db3a5
원인 분석/문제 해결 시도
1) 화이트보드 화면이 언제 참여자 페이지에 렌더링 되는 건지 확인하기
(로컬에 미디어 서버를 띄우고 테스트해봤습니다.)
231201.mp4
video의 메타데이터가 로드되었을 때 발생하는
loadedmetadata
와 함께 화면에 영상이 재생되는 것을 확인했습니다.2)
loadedmetadata
가 왜 늦게 발생하는가?여러가지 시도 끝에 알게 된 것은 강의자 페이지에서 강의자가 캔버스에 아무런 동작(펜 그리기, 이동, 줌인 등)을 하지 않으면 상대방에게
loadedmetadata
는 일어나지 않는다는 것입니다.https://w3c.github.io/mediacapture-fromelement/#methods-0
이는
CaptureStream()
의 알고리즘 문제로, 캔버스에서 내용이 변경될 때까지 캡처된 트랙이 시작되지 않기 때문으로 보입니다.CaptureStream()
메서드 자체가 잘 사용되지 않고 있고, 업데이트가 거의 없어 이러한 옵션을 끄는 것이 불가능한 상태입니다.이를 해결하는 방법으로
CanvasCaptureMediaStreamTrack
에는 requestFrame()이라는 함수가 있으나 track의 시작은 requestFrame() 이후 추가적인 캔버스 내용 변경시에 반영되어 문제를 해결할 수는 없었습니다.해결 방법
1) 강제로 canvas 내용을 업데이트 해서 해결하기
fabric.canvas의 메서드인
renderAll()
를 onFrame 함수에 추가해서 계속 다시 렌더링 해주는 방식으로 문제를 해결했습니다.231203-1.mp4
변경 전 : 획을 추가해도 트랙이 시작되지 않음. canvas의 내용이 크게 변해야 전송 시작
231203-2.mp4
변경 후 : 강의자가 canvas에 아무런 변화를 주지 않아도 참여자에게 화면이 바로 나타남.
2) 성능 문제는 없는지 확인하기
성능 문제는 없는지 테스트 해보겠습니다. 첫번째로, onFrame에
renderAll()
함수가 추가되어 발표자 브라우저에서 오버헤드가 발생하는 일은 없는지 테스트 해보았습니다.먼저, 저의 PC에서는 메모지나 선을 여러 개 생성하고 움직임을 해보아도 특별히 버벅임이나 CPU 사용량이 증가하지는 않았으나, 보다 정확한 차이를 확인하기 위해 개발자도구의 성능 탭을 활용하여 비교해 보았습니다.
동일하게 10초간 성능을 측정해 보았고, 5초 즈음에 강의 시작 버튼을 눌러 측정해본 결과입니다.
위가
renderAll()
함수가 없을 때의 결과이고, 아래가renderAll()
함수가 onFrame 함수로 매 프레임마다 실행되었을 때의 결과입니다.cpu사용량이나 프레임 등을 비교했을 때 특별한 차이는 발견하지 못했습니다.
정리 (선택)
추가적으로 미디어서버에 부담이 더 증가하는지, 비디오의 용량이 더 증가하는지 테스트가 필요합니다. 주중에 배포된 미디어서버를 이용해서 테스트 해보겠습니다.
스크린샷(필수 X)
여기에 작성하세요