C++에서 GTK + GUI를 어떻게 시간이 오래 걸리는 작업으로 업데이트합니까?

OpenMP를 사용하여 시간이 많이 소요되는 작업을 수행하고 있습니다. ProgressBar를 GTK +에서 작업을 수행하는 동시에 시간이 많이 걸리는 루프 내에서 업데이트 할 수 없습니다. 내가 가지고있는 코드는 ProgressBar를 갱신했지만, 모든 것이 끝난 후에는 그렇게한다. 코드가 진행되는 것처럼 아닙니다.C++에서 GTK + GUI를 어떻게 시간이 오래 걸리는 작업으로 업데이트합니까?

이 모든 작업이 완료 될 때까지의 ProgressBar를 업데이트하지 않습니다 내 더미 코드 :

void largeTimeConsumingFunction (GtkProgressBar** progressBar) { 

    int extensiveOperationSize = 1000000; 

    #pragma omp parallel for ordered schedule(dynamic) 
    for (int i = 0; i < extensiveOperationSize; i++) { 
     // Do something that will take a lot of of time with data 

     #pragma omp ordered 
     {   
      // Update the progress bar 
      gtk_progress_bar_set_fraction(*progressBar, i/(double)extensiveOperationSize); 
     } 

    } 
}

나는 동일한 작업을 수행

만의 OpenMP를 사용하지 않고이 같은 일이 발생. 끝날 때까지 업데이트되지 않습니다.

루프가 작동하면서 동시에 GTK + 위젯을 업데이트 할 수 있습니까?

편집 : 이것은 짧고 읽기 쉬운 더미 코드입니다. 그것은 실제 코드와 구조가 같지만 실제 코드에서는 처리 할 항목의 크기를 직접 알지 못합니다. 10 개 또는 1 백만 개 항목이 될 수 있으며 각 항목에 대해 몇 가지 조치를 취해야합니다.

출처

2017-05-19 g_l

진행률 표시 줄을 단조롭게 늘리려면 GTK + 문제와 상관없이 루프 내에서 '#pragma omp critical'대신 '#pragma omp ordered'를 사용해야합니다! 주문을 권하지는 않지만 성능이 떨어질 수 있습니다. – Zulan

팁 주셔서 감사. 나는 그것을 그렇게 바꿀 것이다. 비판적인 것은 실제로 주문한 방식이 아니지만 궁금합니다 ... 제가 이미 위에 주문한 경우, 비판적으로 지시 된 방식으로 처형되고 있음을 의미합니까? 아니면 여전히 중요한 영역에 무작위로 들어가는 하나의 스레드입니까? 더 간단한 단어로는 내가 만든 선언 된 정렬 된 영역이 중요한 영역을 포함하는지 여부를 알지 못합니다. 그렇기 때문에 중요에 액세스하는 스레드는 순서대로 있습니다. –

'ordered ordered'는 'ordered'구조가 없으면 의미가 없습니다. – Zulan

여기에 두 가지 잠재적 인 문제가 있습니다 : 당신이 메인 스레드를 차단할 수 있습니다 오래 실행되는 계산을 수행하는 경우

먼저, 당신은 UI 반응을 (유지하기 위해 다음 때때로

while (gtk_events_pending()) 
    gtk_main_iteration();

를 호출해야 여기에는 자체 그리기가 포함됩니다.

둘째, call GTK+ functions only from main thread이어야합니다.

출처

2017-05-19 07:36:47

감사합니다. 그것은 예상대로 작동합니다. –

C++에서 GTK + GUI를 어떻게 시간이 오래 걸리는 작업으로 업데이트합니까?

답변

관련 문제