Hallo,
Bedankt voor de reacties. Dat "voelt" altijd goed
In mijn vorige bijdrage vertelde ik dat het opbouwen van het scherm erg traag werd bij gebruik van meer dan 100 tegels.
Vandaar dat ik even terug moest naar de tekentafel.
Inmiddels lijkt nu alles een stuk vlotter te werken.
Wat was het probleem?
In mijn eerste ontwerp van de layout UI werden er Tegels op een Container Component geplaatst (in Java een JPanel).
Iedere tegel heeft een eigen render methode waarmee die zichzelf kan tekenen.
Deze tegel objecten werden allemaal geërfd van het generieke Shape Object, maar waren geen Componenten in de zin van de JDK.
Wanneer een tegel opnieuw gerenderd moest worden, bv als een wissel van status veranderd werden nu alle tegels opnieuw getekend, omdat er geen "flag" o.i.d. was die kon aangeven welke tegel nu veranderd was. Dit tekenen duurde per tegel tussen de 2 en 10 ms afhankelijk van de soort tegel.
Dan dient binnen de Java Swing API ook alle render activiteit te gebeuren in de z.g. "Event Dispatch Thread".
De JDK doe dit min of meer zelf en daar heb je in weze geen, of weinig invloed op. Dit zorgde voor vertraging.
Vandaar dat bij meer als 100 tegels de totale tekentijd flink kon oplopen (heb tot aan 2000 ms gemeten).
Het mag duidelijk zijn dat dit geen houdbare oplossing was.
Wat is er veranderd?
Een heleboel
Waarschuwing het wordt een beetje "nerd" technisch O:-D
Iedere tegel erft nu van JComponent en volgt het Swing API MVC (Model, View en Controller) patroon.
De tegels worden nu aan de Container toegevoegd i.p.v. getekend.
De Container beschikt over standaard functionaliteit om alleen te renderen wat is gevraagd te renderen.
Ik kan nu dus 1 specifieke tegel opnieuw renderen.
Dit scheelt veel tijd.
De tegel objecten zijn nu opgebouwd in de volgende structuur:
- jcs-gui-componenenten.png (91.61 KiB) 854 keer bekeken
Een Tegel heeft een TileModel, dit object geeft alle (veranderbare) data van de tegel.
Denk bv aan de stand van een wissel, de status van een blok of sensor.
Een tegel heeft ook een TileUI dit object heeft alleen de render code (de hele code wordt nu ook makkelijker te volgen door de heldere scheiding van verantwoordelijkheden).
Door gebruik te maken van overerving erft ieder specifiek layout object van Tile dat een abstracte klas is geworden.
Als voorbeeld een Straight (recht stuk) die erft van Tile.
Heeft een TileModel (hier wordt in opgeslagen of die horizontaal of verticaal is). Heeft een StraightUI object dat de code bevat on een Straight te kunnen tekenen.
De StraightUI erft van ComponentUI uit de JDK, dit object is verantwoordelijk voor het renderen van objecten op een canvas.
Een Switch (Wissel) erft weer van Straight daar een wissel bestaat uit één rechte en één diagonaal etc.
Door deze aanzienlijke verbouwing moest alle aansturing van de de tegels ook anders.
Hierdoor werden dus grote delen van de code geraakt.
Een van de grootste veranderingen is de invoering van een EventAction Queue.
Deze dit tussen de tegels waar je op kunt klikken (Switch, Signal and Sensor) Het event van deze tegel wordt nu op deze Queue gezet.
Aan de andere kant van deze Queue "loopt" een HandlerThread. Deze Thread "kijkt" of er een actie event op de Queue staat en handelt dit vervolgens af (zoals het omzetten van een wissel of sein).
Dit word nu volledig buiten de EventDispatch Thread gedaan, zodat deze dus niet wordt "opgehouden" door het uitvoeren van allerlei (tijd consumerende) taken (In de voorgaande versie = werd dit met een z.g. worker Thread gedaan maar dit werkte minder goed).
Het ontkoppelen van verantwoordelijkheden door een queue werkt erg goed (beter dan lossen "worker" threads zoals ik nu gebruik), dus ben nu met een refactor slag bezig om meer taken zo te laten lopen.
Kortom het gaat weer vooruit, maar nog een hoop te doen voordat het zover is dat ik een release kan maken.
Wordt vervolgt,
Frans
