Fare un progetto in crowdsourcing su Canvas - pagina 18
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Sfortunatamente, i tentativi odierni di far fronte al problema dell'aggiornamento ritardato dell'immagine salvando un array con una "maschera digitale" non hanno avuto successo. Tuttavia, non è nemmeno un fallimento. Semplicemente non è stato possibile trarre una conclusione definitiva sulla causa del ritardo e trovare una soluzione globale al problema.
Nel pensare ai metodi generali per immagazzinare l'immagine finita nella memoria e lavorare con le sue aree, ho esaminato varie opzioni. Quelli che pensavo fossero una buona soluzione, ma che dopo una profonda riflessione si sono rivelati poco pratici.
E così - le mie conclusioni:
1. Se volete salvare le immagini in array, ci dovrebbero essere molti array. Cioè, ogni risorsa richiede il proprio array di memoria costante. Nella mia implementazione, il numero di tele (risorse, tele) potrebbe essere diverse volte maggiore del numero di finestre.
Vi spiegherò perché:
In alcuni casi questo approccio è molto più conveniente che disegnare tutti gli oggetti della finestra su un canvas, per esempio quando si fa scorrere una tabella in un elemento "field of view (VEIW BOX)", è conveniente mettere gli elementi della tabella su un canvas separato dentro questo elemento e far scorrere questo canvas come un oggetto intero. La velocità di scorrimento è più veloce. Quindi, ogni elemento di questo tipo porta un kanvas separato al suo interno. Altrimenti dovrà sovrascrivere l'intera immagine della finestra salvata in memoria. Questo vi porterà sicuramente via molto più tempo.
Inoltre, è abbastanza scomodo disegnare tutte le finestre su una tela, come spostarle allora? Supponiamo di creare una tela "mega" per tutta l'area del grafico. Tutte le nostre finestre saranno disegnate su di esso. Dopo aver disegnato le finestre sul kanvas, proveremo a spostarle, ma per farlo dovremo riscrivere l'intera immagine di questo singolo "mega" kanvas. Il quadro è molto grande e la quantità di valori riscritti sarà enorme. Anche se l'immagine viene salvata, dovremo sovrascrivere un'area enorme nella memoria ad ogni spostamento del cursore. Ovviamente questo è inefficiente.
2. Pensando a un metodo per salvare le immagini e lavorare con esse, mi sono ricordato della funzione "ResourceReadImage()". Questa funzione legge la risorsa e mette la sua maschera numerica in un array. Quindi, - non c'è bisogno di salvare l'immagine, perché è già salvata a livello del terminale e può essere richiamata con questa funzione. Questo semplifica notevolmente il compito. E così: si può recuperare l'immagine con "ResourceReadImage()", ottenerla in un array e poi cambiare i valori dell'array, relativi a un elemento particolare che è "sotto l'evento" dell'interfaccia. Questo approccio sembra più attraente, secondo me. Tuttavia, la domanda rimane - quanto tempo ci vorrà per riempire l'array con un'immagine usando "ResourceReadImage()"? Ovviamente, questo dipende anche dall'area del kanvas. Potrebbe non essere affatto visibile, ma in ogni caso dovrebbe essere caricato solo una volta mentre il cursore si trova su una particolare area del kanvas. Quando ti sposti su un altro kanvas, puoi cancellare l'array e caricare l'immagine dell'altro kanvas.
Comunque, non ho una soluzione definitiva in questo momento. Devo provare con la funzione "ResourceReadImage()", misurare il tempo di caricamento dell'immagine e sviluppare un sistema di lavoro con aree di immagine nell'array.
Questo è tutto per ora.Реter Konow:
Nella mia implementazione dell'interfaccia, il numero di tele (risorse, tele) può essere diverse volte maggiore del numero di finestre. Questo è richiesto dalla pratica.
La tua pratica lo richiede.
Ma come dimostra la vostra pratica - questa implementazione è difettosa in termini di velocità e convenienza.
Come dimostra la pratica, è più conveniente lavorare con una sola tela e non ci sono ostacoli per disegnare temporaneamente la finestra della tabella sulla tela e poi usare BitBlt su quella principale.
Non so perché avete pianificato "ci devono essere molti array". "Ma tu stesso vedi che è una strada senza uscita.
Questo è ciò che richiede la vostra pratica.
Ma come dimostra la vostra pratica - tale implementazione è imperfetta in termini di velocità e convenienza.
Come dimostra la pratica, è più conveniente lavorare con una sola tela e non ci sono ostacoli per disegnare temporaneamente la finestra della tabella sulla tela e poi usare BitBlt su quella principale.
Non so perché hai previsto "ci devono essere molti array, inoltre - indefinitamente molti... "Ma tu stesso vedi che è una strada senza uscita.
Forse avete trovato una soluzione migliore. Mi piacerebbe vederlo. Se potete, postate una gif dove si vede chiaramente la velocità di risposta degli elementi al clic. Dopo posterò la mia gif. Tu vedrai di cosa sto parlando e io vedrò di cosa stai parlando tu.
Non ho registrato il video, ma ti mando un esempio, è uno schizzo veloce.
Ci sono 600 elenchi a discesa.
Muovi il mouse - con ogni evento e cambio di colore il CCanvas complessivo viene ridisegnato. Ottieni questa interattività.
Puoi vedere la dimensione finale nelle proprietà della bitmap - 1500x600 px (rispetto al tuo 800x500 e 250ms di ritardo). Il che equivale a 900.000 pixel, e tutti vengono ridisegnati istantaneamente. Nessun secondo è fuori questione.
Ogni lista è resa prima sulla sua tela nella sua propria dimensione (per non farla traboccare) e poi viene arata sull'insieme. Quindi abbiamo 600 chiamate ResourceCreate per ogni evento del mouse.
Questo significa, come si può vedere dalla velocità di reazione, che i fotogrammi sono sufficienti per mostrare i cartoni animati.
Gli sviluppatori di MT hanno dato uno strumento soddisfacente senza lag (intendo ResourceCreate bitmap)
Non ho registrato il video, ma vi mando un esempio.
ci sono 600 elenchi a discesa.
Muovi il mouse - con ogni evento e cambio di colore il CCanvas complessivo viene ridisegnato.
Puoi vedere la dimensione finale nelle proprietà della bitmap - 1500x600 px (rispetto al tuo 800x500 e 250ms di ritardo). Il che equivale a 900.000 pixel, e tutti vengono ridisegnati istantaneamente. Nessun secondo è fuori questione.
Ogni lista è resa prima sulla sua tela nella sua propria dimensione (per non farla traboccare) e poi viene arata sull'insieme. Quindi abbiamo 600 chiamate ResourceCreate per ogni evento del mouse.
Questo significa, come si può vedere dalla velocità di reazione, che i fotogrammi sono sufficienti per mostrare i cartoni animati.
Gli sviluppatori di MT hanno dato uno strumento soddisfacente senza lag (intendo ResourceCreate bitmap)
Bene, questo è abbastanza per confermare le sue parole... Tuttavia, ripeto la mia domanda di ieri: l'immagine viene salvata?
Ho detto ieri - se si memorizza un'immagine creata una volta, si cambia solo un'area specifica in essa, e si invia a ResourceCreate() immediatamente, non ci sarà alcun ritardo. Il tuo metodo di lavoro con la tela non mi è ancora familiare. Non so ancora come avete ottenuto questo risultato.
Ho un'altra domanda: usando la classe CCanvas per creare l'esempio di cui sopra, potresti descrivere il principio di implementazione di questa soluzione?
Forse le operazioni bitwise sono usate lì per elaborare l'immagine. Non ho ancora avuto a che fare con loro.
P.S. Tuttavia, mi piace risolvere i segreti da solo...) Risolverò comunque questo problema.
usando la classe CCanvas per creare l'esempio di cui sopra, puoi descrivere il principio di implementazione di questa soluzione?
il principio è lineare - passa attraverso l'elenco dei controlli e disegna ognuno di essi nella posizione richiesta sulla tela.
Solo le funzioni CCanvas sono utilizzate per disegnare i controlli. Non ho fatto nulla di mio.
ad esempio, le liste in forma compressa sono disegnate come due elementi - in questo esempio, pulsanti (questo è diverso in altri stili)
le funzioni della tela sono chiamate
FillRectangle // riempire lo sfondo
Rettangolo // cornice intorno
FontSet // imposta font
TextOut // testo in uscita
È possibile che lì vengano utilizzate operazioni bitwise per elaborare l'immagine.
no.
l'immagine è salvata?
sì, nell'array che è in CCanvas
se si memorizza un'immagine una volta creata, si cambia solo un'area specifica in essa, e la si invia immediatamente a ResourceCreate(), non ci sarà alcun ritardo.
non del tutto giusto.
Nel mio esempio l'intera matrice viene ridisegnata. L'array viene cancellato e l'intera tela viene riempita di nuovo ad ogni ridisegno. Poi viene chiamato ResourceCreate.
Nel mio esempio l'intera matrice viene ridisegnata. L'array viene cancellato e l'intera tela viene riempita di nuovo ad ogni ridisegno. Poi viene chiamato ResourceCreate.
Grazie per la risposta elaborata.
Stranamente, è lo stesso per me. L'immagine dell'intera finestra è completamente ricreata ad ogni evento dell'interfaccia. È costruito in un array locale unidimensionale, che viene inviato a ResourceCreate dopo il completamento di questa procedura.
Non so perché mi rallenta... Domani posterò una gif dove mostrerò la correlazione tra la dimensione della finestra e la velocità di risposta dell'articolo.
Tutto questo è molto strano...
Grazie per la risposta dettagliata.
Stranamente, è lo stesso per me. L'immagine dell'intera finestra è completamente ricreata ad ogni evento dell'interfaccia. È costruito in un array locale unidimensionale, che viene inviato a ResourceCreate dopo il completamento di questa procedura.
Non so perché mi rallenta... Domani posterò una gif dove mostrerò la dipendenza tra la dimensione della finestra e la velocità di risposta dell'articolo.
Tutto questo è molto strano...
Se non è difficile, fate un'animazione gif con il carico della CPU nel task manager. Oppure è più facile postare il file compilato, come ha fattosergeev. Così uno può testarlo da solo.
OK, farò un video del carico della CPU. Ma riguardo al file compilato - non lo posterò ancora.
Mi vergogno molto degli insetti...))
Quando li sistemo, prometto di postarli.
OK, farò un video del carico della CPU. Ma riguardo al file compilato - non lo posterò ancora.
Mi vergogno molto degli insetti...)))
Quando li sistemo - prometto di pubblicarli.