Fluid: condivisione, domande e considerazioni su performance (con video!)

[theguru]

Buongiorno a tutti.
A seguito delle mie prove su fluid, ho fatto un video nel quale illustro la mia principale perplessità, all’oggi, ovvero la sua effettiva “fluidità” sul campo, paragonato a rd3.

Sintetizzo quanto ho potuto rilevare, probabilmente a causa di qualche mia particolare architettura: la velocità dell’interfaccia, la sua fruibilità, sembra aver avuto un peggioramente rispetto a rd3, intasando il v8 di chrome con js molto più voraci di risorse.

Aggiungo come ulteriori note:

• sono stra-contento della nuova filosofia CSS oriented, ma a questo proposito vi chiedo di sistemare un “vecchio problema” del framework, ovvero l’impossibilità, dentro on_dynamic_properties, di gestire le classi CSS direttamente o tramite reflection, senza passare dai visual style.
• mi sarei aspettato, dopo la vostra presentazione, diversi problemi sulla implementazione di elementi a contatto, ma per adesso sembra gestibile molto bene
• ci sono piccole cose implementate davvero meglio, ad esempio, il contenuto dei button gestito tramite uno span interno, e non tramite attributo value (come avviene in rd3), e tante altre modernizzazioni che non sto ad elencare, l’html di rd3 sembra davvero uscito dalla fine anni 90…
• sottolineo che si tratta dei miei primi passi, ma prima di proseguire (investendo non poche risorse nella migrazione) vorrei davvero aver più chiaro l’impatto sulle risorse del client.

Per spiegare meglio quanto sopra, ho fatto un video, dove ho buttato dentro analisi “tecniche” e considerazioni quasi filosofiche, in effetti sono andato un po’ lungo, sentitevi liberi di guardarlo a pezzetti come meglio preferite.
Non riesco ad inserire iframe su questa piattaforma, quindi potete scaricarlo qui:
https://www.screencast.com/t/U2xkxgtgb

Non ho implementato i chapter, ma vi elenco qui sotto i timestamp delle sezioni:

• 00:00 intro
• 02:43 comparazione “fluidità” dei due motori a livello percettivo
• 06:40 analisi con profiler (chrome)
• 17:40 considerazioni su INDE cloud e form con molti elementi
• 19:52 intro su CSS
• 22:17 suggerimento evolutiva su INDE

ok, spero nel mio piccolo di aver contribuito, attendo commenti, grazie in anticipo a tutti coloro che vogliano aggiungere qualcosa.

[paolo.giannelli]

@theguru grazie di questa analisi e della condivisione con tutti di un video per spiegare le tue impressioni e osservazioni.
Il contributo di tutti servirà a migliorare FLUID per renderlo sempre più efficace e utile al lavoro di tutti.

Sulla questione performance ci stiamo già lavorando.

In questi giorni sono molto preso dal rilascio di Cloud 23.0 ma mi pianifico l’analisi del tuo video a breve.

[d.pierangeli]

Per quanto riguarda le prestazioni confermo che è un problema a cui stiamo lavorando, soprattutto per quello che riguarda lo scroll.

Un prima ottimizzazione sarà già presente nel prossimo rilascio, altre ottimizzazioni sono in corso.

Per quanto riguarda l’avvio probabilmente va ottimizzato l’accesso alla proprietà CSSStyle, usata per generare a run-time i css degli stili visuali.
Ho creato una issue apposita per tenerne traccia e ottimizzare anche quello.

[theguru]

Ciao.
C’è stata qualche evoluzione a tale riguardo?
Avrei davvero piacere di studiare - utilizzare - contribuire al miglioramento di fluid, ma prima di dedicarci la marea di tempo che servirà vorrei avere qualche rassicurazione in più sugli aspetti tecnici che ho segnalato.
A mio avviso tracciano una linea rossa abbastanza importante, vorrei capire da che lato finiremo
Grazie!

[theguru]

Salve di nuovo. Mi trovo un poco in imbarazzo ad insistere su questa correzione, forse non interessa a molti ma comunque provo a chiedere: prima della release 23, che sembra essere alle porte, avete analizzato e corretto il problema? Vi ringrazio della risposta,E

[a.marino]

Ciao @theguru, intanto colgo l’occasione per ringraziarti per l’interessante video di analisi che hai condiviso.

La versione 23.0 include tantissime correzioni e miglioramenti di Fluid, grazie alle segnalazioni che ci sono arrivate da voi che lo avete provato. Include anche delle ottimizzazioni, in particolare per quanto riguarda i due aspetti più critici: lo scrolling della lista del pannello e la generazione degli stili visuali all’avvio dell’app.

Proprio per quanto riguarda quest’ultimo punto (che poi si riallaccia ad un parte del tuo video), ci tenevo a illustrarti brevemente come funziona su Fluid la generazione dei visual style e il perché quel numero di chiamate ai metodi di generazione degli stili visuali sia corretto.

All’avvio dell’app il server invia la definizione degli stili visuali. Per ogni stile visuale (rappresentato dalla classe IdfVisualStyle), Fluid genera un set di classi css (che riguardano principalmente pannelli e book).

In particolare vengono generate 22 classi, delle quali la maggior parte vengono poi applicate agli oggetti di interfaccia in base al loro tipo (ad esempio .vis1-panel, .vis1-formField, .vis1-listGroup, ecc.) ed altre vengono applicate in base allo stato degli oggetti (ad esempio .errorField, .warningField, .readOnlyField, ecc.).

Le 22 classi definiscono in tutto 96 regole css tra background-color, border, font-size, ecc.
Un nuovo progetto definisce già 41 stili visuali, quindi il numero di iterazioni necessario a creare tutte le regole di tutti gli stili visuali sarà 41*96=3963 già di base. E ovviamente questo numero cresce in modo lineare al crescere del numero degli stili visuali.

Volevo poi aggiungere che Fluid è un prodotto che non abbiamo intenzione di “inscatolare” e considerare finito nel senso di metterci mano il meno possibile. È nel pieno della sua evoluzione e quindi continueremo a migliorarlo e a ottimizzarlo anche grazie a contributi come il tuo.

Spero di aver chiarito un po’ dei tuoi dubbi

[theguru]

Grazie a te per le spiegazioni.
Leggendo la tua analisi, credo sia normale, mi sono venute in mente non poche osservazioni, ma credo abbia poco senso parlarne ora.
Attendo quindi la prossima release, a prescindere dal numero di iterazioni spero che la percezione / UX sia per l’appunto… fluida
Grazie ancora!

[theguru]

Eccomi.
Scaricata ed installata la 23, fatti i test, purtroppo vi devo aggiornare con risultati davvero poco incoraggianti.
La notizia buona, l’attesa di circa 30 secondi all’avvio della applicazione si è ridotta a 4/5 secondi, molto meglio ma sempre maggiore del < secondo di RD3. Notare che di questo secondo scarso 6/8 decimi me li prendo io per ops di backend, quindi la differenza peggiorativa, in percentile, è notevole.

Alla chiamata del primo form, e quindi del primo pannello con lista, questo finisce di disegnarsi in circa 8/9 secondi, contro il mezzo secondo di RD3. IL pannello di debug riporta infatti 300/400 ms di codice, tutto il resto è js.
Vi inserisco qui sotto i warning di performance della console ed anche un disegno della lista stessa, in modo che possiate farvi un idea.

quella che segue è la schermata disegnata, ho rimosso i pannelli figli a dx per alleggerire quanto posso:

Se provo a scrollare la lista, la situazione, a livello percettivo, peggiora: ho attese di 1/2 secondi, con lo spazio che rimane per poco congelato con i vecchi dati, poi diventa vuoto con solo background color, poi disegna le linee di tabella, poi le popola con dati. Ognuna di queste operazioni viene eseguita non in un colpo unico, ma in 2/3 step, a seconda.
Riporto i warning in console durante uno scroll di circa mezza pagina:

Non so davvero che dire, forse sono i miei applicativi che proprio non quagliano con INDE cloud, ed altri utenti avranno esperienze molto migliori, magari usando form molto semplici o liste paginate che nascondono i problemi qui sopra. Da quello che ho capito questa doveva essere la versione dedicata alla ottimizzazione di FLUID, e ci resto un po’ così.

PS: i file custom.css e custom.js sono stati rimossi, come tutta la cartella custom, quindi siamo partiti vanilla. Ovviamente nel html sono presenti classi customizzate mie, ma non vedo come queste potrebbero dar fastidio.

[r.bianco]

Grazie dei test e della condivisione.
Da come l’ho intesa io, l’uso del motore FLUID richiede logiche di interfaccia/caricamento dati/etc… differenti da quelle di RD3, per cui credo sia difficile la sua applicazione su progetti mediamente complessi sviluppati in RD3, a meno di non rivedere tali logiche.
Il mio commento rimane nell’area delle ipotesi, vediamo Progamma che dice.
Forse sarebbe interessante che tu vedessi direttamente con loro (Luca? Giuseppe? Antonio?) la tua applicazione di test, pe capire quali modifiche sono necessarie per renderla ottimizzata per Fluid.

[g.buttafoco]

Fluid annasapa un po’ rispetto ad RD3 anche nel caso di una tabella con poche righe (500 di cui una 50ina visibili) e molte colonne (130). Ho un esempio in cui volevo replicare una griglia tipo excel senza DynamicProperties e con tutti campi decimal, char, int di lunghezza massima 100, ma in fase di scorrimento verticale RD3 va decisamente meglio.

[theguru]

@a.marino

All’avvio dell’app il server invia la definizione degli stili visuali. Per ogni stile visuale (rappresentato dalla classe IdfVisualStyle), Fluid genera un set di classi css (che riguardano principalmente pannelli e book).

@a.marino una domanda, quando dici “per ogni stile visuale” intendi:

1. per ogni stile visuale che è stato definito a design time
2. per ogni stile visuale che è in effetti utilizzato dalla applicazione
3. per ogni stile visuale utilizzato nella form (videata) corrente

?
perchè nel caso 1, che immagino possiate aver utilizzato per velocizzarvi le cose, avrebbe ancora più senso fare quello che vorrei fare da sempre, ovvero NON utilizzare i malefici visual style del tutto (giusto i vostri 4 o 5 di default), cosa che potrei fare se correggeste quell’atavico problema della proprietà css_class che non si setta correttamente all’interno dell’on_dynamic_properties.
Grazie della risposta,
E

[a.marino]

@theguru esatto, intendo il punto 1. Vengono definite le classi css di ogni stile visuale e viene creato un css che le contiene tutte.

Per quanto riguarda la proprietà css_class è vero quello che dici, cioè che non può essere impostata sulle celle tramite l’onDynamicProperties. Questo perché non è una proprietà dinamica e quindi vale solo per la colonna. È proprio il sistema che funziona così. C’è una NPQ di miglioramento per rendere dinamica anche la proprietà css_class (NPQ03225).

Quindi sì, diciamo che allo stato attuale volendo puoi fare a meno dei visual style per personalizzare lo stile del pannello e dei campi, ma ne hai bisogno per personalizzare lo stile delle celle.

[d.termini]

@a.marino

esatto, intendo il punto 1. Vengono definite le classi css di ogni stile visuale e viene creato un css che le contiene tutte.

Ma a questo punto non è forse meglio generare anche quella parte di css in fase di compilazione e non a runtime? Tanto sarà sempre uguale visto che tratta gli stili generati a design.

[a.marino]

@d.termini

Ma a questo punto non è forse meglio generare anche quella parte di css in fase di compilazione e non a runtime? Tanto sarà sempre uguale visto che tratta gli stili generati a design.

In effetti ha senso. Inizialmente volevamo evitare, per quanto possibile, di far fare all’IDE cose specifiche per Fluid, quindi abbiamo lasciato a Fluid stesso il compito della generazione del css derivato dagli stili visuali.

Però questa è un’idea molto interessante: generare il css in fase di compilazione e poi lasciare a Fluid solo la gestione dell’aggiornamento differenziale, quando si modifica un visual style a runtime.

Me lo segno come miglioramento per un prossimo rilascio, grazie!

[theguru]

@a.marino

Però questa è un’idea molto interessante: generare il css in fase di compilazione e poi lasciare a Fluid solo la gestione dell’aggiornamento differenziale, quando si modifica un visual style a runtime.

Me lo segno come miglioramento per un prossimo rilascio, grazie!

Abbiate tutti pazienza, benché quanto proposto da @d.termini abbia assolutamente senso, il miglioramento non consiste in una gestione diversa dei visual style, ma nel dare finalmente la possibilità agli utenti di non usarli!
ragazzi è roba uscita dagli anni 90, dateci la possibilità di assegnare le classi CSS direttamente, davvero, è importante.

E vi prego, guardate cosa c’è che non va in queste liste: non è possibile che un motore js scritto più di 20 anni fa sia più veloce (a questi livelli) di un prodotto attuale. Vedo i framework generare liste di migliaia di elementi che scorrono fluide da far impressione: Su fluid per scorrere mezza pagina, una 20ina di righe, si vede chrome che ridisegna l’interfaccia pezzo pezzo in un paio di secondi. Su un core i9! E no, non sono lookup, son tutti js…

[tommaso.simoncini]

Per quanto possa valere il mio contributo, io sono completamente d’accordo con @theguru.
Sto seriamente valutando di riscrivere il front-end della mia applicazione IDF per passare da uno ZEN abbastanza personalizzato a Fluid.
Se però le premesse sono queste, non inizio neanche a fare i primi prototipi. Abbiamo un’app usata da migliaia di utenti concorrenti, che hanno griglie di documenti con anche migliaia di righe.

Deve esserci un miglioramento sia della presentazione dei dati, sia di performance (client e server).

Domanda per @a.marino: prima di rilasciare Fluid, avete fatto degli stress-test interni per capire come reagiva il framework con pannelli di decine di colonne e migliaia di righe?
Immagino di sì. Che risultati avete ottenuto?
Magari @theguru ha qualcosa di specifico nel suo progetto che non faceva parte dei vostri test.

[a.marino]

Fluid ovviamente è stato testato completamente prima del rilascio, ma sulla base di quello che segnalate potrebbero esserci state delle regressioni. Stiamo lavorando per verificare la cosa e apportare le ottimizzazioni necessarie.

[stefano.masiero]

Ciao
dobbiamo rivedere la UI su un’applicazione su cui usiamo tema bootstrap con diverse personalizzazioni sia css che js.

Vorrei passare al tema Fluid/Vela e probabilmente molte personalizzazioni non mi serviranno quindi è la parte che mi preoccupa meno.

Leggendo dei problemi di performance segnalati in questo thread mi è sorto però qualche dubbio.

Dato che l’ultimo post è di novembre 2023 e nel frattempo sono stati fatti diversi miglioramenti vorrei sapere se qualcuno ha verificato se permane la presenza dei problemi descritti.

Grazie
Stefano