Le idee esposte nell’articolo precedente sono state implementate. Non so se alla perfezione perché non ho avuto molto interesse nel testarle bene visti i continui problemi, ma sembra comunque risolto il problema del tag <g>.

Non capisco per quale fottuto motivo ma i disegni e le loro coordinate sono sfasati nel tempo. Sono asincroni, perché le coordinate alle quali vengono visualizzati dipende da quanto zoom /drag hai fatto da quando hai richiesto il disegno. Ciò è palese con lo zoom: compaiono in posti diversi in base a quanto velocemente hai zoomato.

Ovviamente so il punto della logica del codice dove questo problema, perché sono pochi i punti del codice in cui vengono richiamate funzioni sincronicamente rispetto al resto dell’esecuzione. Ma cazzo il calcolo di dove visualizzarli avviene appunto dopo queste chiamate, quindi in modo sincrono rispetto alla reale aggiunta alla dashboard.

Quindi che cazzo gliene frega al codice se quando ho richiesto il disegno dal server avevo un livello di zoom  e coordinate assolute diverse?

1) mouseWheel

2) “quando hai tempo” fai lo zoom

3) zoom della dashboard attuale e richiesta dei disegni nuovi

4) “quando ricevo un disegno” calcolo dove visualizzarlo in base alle coordinate / zoom attuali.

Che cazzo me ne frega se ci sono passaggi asincroni? Tanto dal server ricevo sempre le coordinate assolute, e la conversione a relative è fatta solo al momento della reale visualizzazione, in base allo stato della dashboard in quel momento.

Che cazzo ne so

Comunque una news interessante oggi c’è. A lavoro mi stanno insegnando parecchio su come testare le reali performance di ogni parte del codice, l’utilizzo di memoria, e tempi di esecuzione di ogni funzione grazie ai tool di chrome. Quando sarà il momento di ottimizzare il codice verrà fuori un prodotto eccezionale.