[FIX] Drag & Drop Window Lag

[ZuZuR]

*Descriere:

FIX pentru fereastra clientului.

*Poze / Video:



*Link download / Code:

Conținut: Ascuns

Reacționează la acest mesaj și conținutul se va afișa automat.

Conținut: Ascuns

Reacționează la acest mesaj și conținutul se va afișa automat.

[GRINCH]

daca ai directx9 iei crush la client cu aceste modificari

[LeH]

daca ai directx9 iei crush la client cu aceste modificari

vezi ca ai in sursa de la zen fixul

[[HF]White]

daca ai directx9 iei crush la client cu aceste modificari

eu am dx9 si nu am crash

[LeH]

daca ai directx9 iei crush la client cu aceste modificari

eu am dx9 si nu am crash

am testat si eu si merge perfect

[champagne]

UPDATE: Am verificat codul și am găsit o problemă care poate cauza undefined behavior.

m_future_should_continue_processing și m_future_acknowledged_stop_request sunt declarate ca bool simplu, dar sunt accesate simultan din două thread-uri — main thread-ul scrie în ele, iar async thread-ul le citește în buclă BeginFutureLoop(). Fără std::atomic, compilatorul nu are nicio garanție că valoarea scrisă într-un thread e vizibilă imediat în celălalt.
Practic ce se poate întâmpla:
— compilatorul ține minte valoarea veche și nu o mai citește din memorie, ignorând complet modificarea făcută de main thread
— async thread-ul rămâne blocat la infinit în while (m_future_should_continue_processing) chiar dacă main thread-ul a setat deja false.

Fix în PythonApplication.h:

Code:

std::atomic<bool> m_future_should_continue_processing;
std::atomic<bool> m_future_acknowledged_stop_request;

Adauga în StdAfx.h

Code:

#include <atomic>

Cu std::atomic te asiguri că atunci când un thread schimbă valoarea, celălalt thread o vede imediat — nu mai există situatia in care fiecare thread lucreaza cu propria versiune a valorii.