[JAVA] Append op TextArea pas na afloop methode

[battler]

Ik heb een klein stukje simpele code

code:

  public static void addText1()
    {
     for(int i = 1; i < 99999; i++)
     {
        MultithreadView.tekst1.append(""+i+ "\n");
     }
    }

Nu voegt deze methode elke keer een nr toe op de volgende regel. Alleen gebeurd dit pas na afloop van deze methode. Dus ik krijg eerst 80% CPU load en niets te zien, en na een sec. of 4 verschijnt in 1 keer alles in de TextArea. Het is toch de bedoeling dat dit gewoon netjes regel voor regel wordt uitgevoerd en toegevoegd?

[enakje]

Als het om een simpele Swing applicatie gaat: je kunt maar 1 ding tegelijk doen. Jij wilt twee dingen tegelijk doen, namelijk de functie uitvoeren en de GUI updaten. Je moet je Swing programma dan omschrijven naar een Swing app met een Worker thread o.i.d.

[momania]

Nee, want je voert dit nu uit in de main thread. De GUI zal dus pas worden ververst als dit klaar is, aangezien het dan pas de kans krijgt om dit te doen.

Dit zal je dus in aparte worker threads moeten doen. Zoek maar eens op de term swingworkers etc.

[battler]

Bedankt, google it is...

[Remus]

Ik zou iig beginnen met de Swing Concurrency tutorial:http://java.sun.com/docs/...ng/concurrency/index.html

[_Noldy]

Je kan hier inderdaad Swingworker voor gebruiken maar een Runnable classe is misschien wel handig. Als dit het enige is wat je wil gebruiken dan zou je deze ook als inner class kunnen definieren.

Ik neem nu even aan dat het is om java te leren. Swingworker is wel de makkelijkste methode maar niet de mooiste in dit geval.

[momania]

_Noldy schreef op maandag 05 oktober 2009 @ 11:08:
Ik neem nu even aan dat het is om java te leren. Swingworker is wel de makkelijkste methode maar niet de mooiste in dit geval.

Care to explain?

Waarom zou een normale Runnable mooier zijn dan een SwingWorker?

[_Noldy]

momania schreef op maandag 05 oktober 2009 @ 11:17:
[...]

Care to explain?

Waarom zou een normale Runnable mooier zijn dan een SwingWorker?

Ik was bang dat ik je het antwoord schuldig moest blijven maar dit is wat ik zojuist uit de api vis:

In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods.

De klasse Swingworker bevat veel meer methodes, vaak heb je die methodes niet eens nodig. Bijvoorbeeld done().

In het geval van battler is het zo dat hij enkel iets wil toevoegen aan een TextArea. Hiervoor hoeft hij niet de alle methodes uit Swingworker te implementeren maar alleen de run() methode uit Runnable. Mede hierom is het mooier om Runnable te gebruiken i.p.v. SwingWorker.

Een SwingWorker wil je dus alleen gebruiken als je iets in een andere Thread wil doen, en het daarbij wil laten.

Wat ik niet weet is of dit ook verschil maakt bij het managen van je Thread-pool.

[RobIII]

Ik begeef me even op vreemd vlak want ik ben niet echt thuis in Java, maar is 't niet veel handiger om een StringBuilder (-achtig) iets te gebruiken, een string te vullen en dan gewoon pas de textarea te vullen met de inhoud van die stringbuilder?

[momania]

Nadeel met normale runnables is wel dat je ze zelf in een thread moet uitvoeren of ergens zelf een threadpool moet managen.
Met de Swingworkers is dat allemaal al voor je afgehandeld en wordt de thread in de workers executor service gegooid.

RobIII schreef op maandag 05 oktober 2009 @ 17:49:
Ik begeef me even op vreemd vlak want ik ben niet echt thuis in Java, maar is 't niet veel handiger om een StringBuilder (-achtig) iets te gebruiken, een string te vullen en dan gewoon pas de textarea te vullen met de inhoud van die stringbuilder?

Ligt er maar net aan of je de updates in de gui direct wilt zien natuurlijk. In dit simpele voorbeeld lijkt me jouw voorstel (processen, verzamelen, gui updaten) ook beter omdat dat gewoon vele malen sneller is
Maar dan evengoed nog wel in een aparte thread anders blokkeert de gui alsnog tot dit klaar is.

[ Voor 58% gewijzigd door momania op 05-10-2009 18:02 ]

[RobIII]

momania schreef op maandag 05 oktober 2009 @ 17:59:
Ligt er maar net aan of je de updates in de gui direct wilt zien natuurlijk. In dit simpele voorbeeld lijkt me jouw voorstel (processen, verzamelen, gui updaten) ook beter omdat dat gewoon vele malen sneller is
Maar dan evengoed nog wel in een aparte thread anders blokkeert de gui alsnog tot dit klaar is.

Het is gewoon dat ik niet weet of 't zich loont om 't in een aparte thread te gooien. Ik heb even in C# gebenched met wat C# en windows specifieke (\n -> \r\n) aanpassingen:

C#:

using System;
using System.Text;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            DateTime s = DateTime.Now;

            StringBuilder sb = new StringBuilder();
            for (int i = 1; i < 99999; i++)
                sb.AppendLine(i.ToString());
            textBox1.Text = sb.ToString();
            Console.WriteLine(DateTime.Now - s);

            s = DateTime.Now;
            for (int i = 1; i < 99999; i++)
                textBox2.Text += i.ToString() + "\r\n";
            Console.WriteLine(DateTime.Now - s);
        }
    }
}

Zoals je ziet zoveel mogelijk equivalent gehouden met de code uit TS.

Output:

00:00:00.0290016
00:01:07.2508466

Een slordige 2300 keer zo snel

Vandaar dat ik 't gedoe met aparte threads niet helemaal zie. Maar again; dit is C#, ik weet niet wat deze bench in Java zou doen. Als mijn GUI 0.02 seconden blokkeert... tjah. Boeie

[ Voor 4% gewijzigd door RobIII op 05-10-2009 18:20 ]

[roeleboel]

@Robill:
het moet in een aparte thread omdat anders al de updates in een keer achteraf komen, nadat het 'echte' rekenwerk al gedaan is.
Feit is inderdaad dat ook in Java een StringBuffer veel sneller is dan String, maar om de updates 'tussendoor' te krijgen (wat hier de hoofdvraag is van de TS) _moet_ er in Swing een aparte thread gebruikt worden.

[RobIII]

roeleboel schreef op maandag 05 oktober 2009 @ 18:19:
maar om de updates 'tussendoor' te krijgen (wat hier de hoofdvraag is van de TS) _moet_ er in Swing een aparte thread gebruikt worden.

Eensch als je de updates tussendoor wil zien, maar a) zie ik er het nut niet van en b) haal ik dat nergens expliciet uit wat de TS zegt her-of-der.

battler schreef op zondag 04 oktober 2009 @ 12:11:
Dus ik krijg eerst 80% CPU load en niets te zien, en na een sec. of 4 verschijnt in 1 keer alles in de TextArea. Het is toch de bedoeling dat dit gewoon netjes regel voor regel wordt uitgevoerd en toegevoegd?

Daar haal ik uit dat 't 4 seconden niets is en dan alles in 1 keer (wat overigens nog gunstig is in zijn geval, anders had een een crapload langer geduurd ) maar nergens dat 'ie het per-se 1 voor 1 wil zien verschijnen. Wel lees ik uit z'n laatste zin dat 'ie verwacht dat de GUI onderwijl bijgewerkt wordt (en wellicht verwacht TS ook dat 'ie daarmee dus nog gewoon z'n GUI zou moeten/willen/kunnen gebruiken). En again; ik zie er dan het nut niet van als TS de updates wél per-se zou willen zien.

[ Voor 52% gewijzigd door RobIII op 05-10-2009 18:27 ]

[momania]

RobIII schreef op maandag 05 oktober 2009 @ 18:23:
[...]

Eensch als je de updates tussendoor wil zien, maar a) zie ik er het nut niet van en b) haal ik dat nergens expliciet uit wat de TS zegt her-of-der.

Toch moet je het in java in een aparte thread doen, ook al wil je je resultaat in 1 keer zien. Punt is nml. dat de default thread waarin je code uitvoert de main thread is en je dus elke andere gui update blokkeert.

---

Het mooiste blijft dan nog om het in Swingworkers te doen. De 'doInBackground' voert je code dan uit in een aparte threadpool. Wil je daarna gui updates doen, stop je die code in de 'done' methode en dat wordt dan weer in een andere aparte threadpool uitgevoerd. Zo zullen je gui updates iig niet ge-queued/vertraagd worden door background processen die (nog) niets met de gui te maken hebben

roeleboel schreef op maandag 05 oktober 2009 @ 18:19:
@Robill:
Feit is inderdaad dat ook in Java een StringBuffer veel sneller is dan String,

offtopic:
En heb je geen thread-safety nodig, dan is de StringBuilder (vanaf jdk 5) nog sneller

[ Voor 42% gewijzigd door momania op 05-10-2009 19:08 ]

[_Noldy]

RobIII schreef op maandag 05 oktober 2009 @ 18:23:
[...]

Eensch als je de updates tussendoor wil zien, maar a) zie ik er het nut niet van en b) haal ik dat nergens expliciet uit wat de TS zegt her-of-der.

[...]

Daar haal ik uit dat 't 4 seconden niets is en dan alles in 1 keer (wat overigens nog gunstig is in zijn geval, anders had een een crapload langer geduurd ) maar nergens dat 'ie het per-se 1 voor 1 wil zien verschijnen. Wel lees ik uit z'n laatste zin dat 'ie verwacht dat de GUI onderwijl bijgewerkt wordt (en wellicht verwacht TS ook dat 'ie daarmee dus nog gewoon z'n GUI zou moeten/willen/kunnen gebruiken). En again; ik zie er dan het nut niet van als TS de updates wél per-se zou willen zien.

Ik denk dat het niet gunstig is in zijn geval. Het is te vergelijken met elk besturingssysteem. Als je alles in dezelfde thread zou doen dan zou bijvoorbeeld Windows moeten kiezen tussen het afspelen van geluid of het weergeven van je afspeelprogramma. Door middel van Threads kun je dit elkaar zo snel af laten wisselen dat je het idee krijgt dat het gelijk gaat. Natuurlijk is sinds de multi core processoren dit vanzelfsprekend mogelijk. Maar er lopen behoorlijk wat Threads op je pc door elkaar heen. Zie je proceslijst in Windows taskmanager maar ook binnen die processen en binnen programmas moet dat kunnen.

[RobIII]

_Noldy schreef op dinsdag 06 oktober 2009 @ 01:03:
Ik denk dat het niet gunstig is in zijn geval.

Wat? Een "freeze" van de GUI voor 0.02 seconden? Want de rest van 't systeem lijdt er niet (echt) onder als 't goed is (en zeker niet als 't maar 0.02 seconden is; het is natuurlijk andere koek als je die gein 60x per seconde gaat uitvoeren waarbij je telkens 0.02 sec. nodig hebt)

_Noldy schreef op dinsdag 06 oktober 2009 @ 01:03:
Het is te vergelijken met elk besturingssysteem. Als je alles in dezelfde thread zou doen dan zou bijvoorbeeld Windows moeten kiezen tussen het afspelen van geluid of het weergeven van je afspeelprogramma. Door middel van Threads kun je dit elkaar zo snel af laten wisselen dat je het idee krijgt dat het gelijk gaat. Natuurlijk is sinds de multi core processoren dit vanzelfsprekend mogelijk. Maar er lopen behoorlijk wat Threads op je pc door elkaar heen. Zie je proceslijst in Windows taskmanager maar ook binnen die processen en binnen programmas moet dat kunnen.

Euh; ik weet wat threads zijn en dat er meer dan 1 proces tegelijkertijd op je systeem actief is dankjewel (Er is overigens een verschil in multitasking _{wat jij beschrijft} en multithreading ). Ik heb 't over 't feit dat ik (vanuit C# oogpunt gezien) 't onzin vind om een aparte thread te lanceren voor 't vullen van een textbox als dit a) "eenmalig" gebeurt, b) een "gui freeze" van 'maar' 0.02 seconden oplevert. Maar als dit onder Java gebruikelijk is dan leef je uit Als 't nou een merkbare/storende 'GUI freeze' zou opleveren dan was, zoals ik 't zie, een aparte thread nog te verdedigen, maar in dit geval lijkt het me gewoon zonde van devtijd. Mind you dat ik die bench niet onder Java heb uitgevoerd en dat 't in dat geval dus best wel eens verdedigbaar zou kunnen zijn als mijn "StringBuilder idee" niet acceptabel snel genoeg zou zijn.

[ Voor 15% gewijzigd door RobIII op 06-10-2009 01:46 ]

[momania]

RobIII schreef op maandag 05 oktober 2009 @ 18:11:
[...]
Zoals je ziet zoveel mogelijk equivalent gehouden met de code uit TS.

Output:

00:00:00.0290016
00:01:07.2508466

Een slordige 2300 keer zo snel

For the record:

Java:

String lineSeparator = "\r\n";
JTextArea area = new JTextArea();
StringBuilder builder = new StringBuilder();

long start = System.currentTimeMillis();
for (int i=0; i<99999; i++) {
    builder.append(i).append(lineSeparator);
}
area.setText(builder.toString());
System.out.println("builder: "+ (System.currentTimeMillis() - start) + "ms");

start = System.currentTimeMillis();
for (int i=0; i<99999; i++) {
    area.append(String.valueOf(i));
    area.append(lineSeparator);
}
System.out.println("textarea: "+ (System.currentTimeMillis() - start) + "ms");

Output:

builder: 313ms
textarea: 1187ms

Wist niet dat textboxen in C# zo sloom zijn

[Woy]

momania schreef op dinsdag 06 oktober 2009 @ 09:31:
[...]
Output:

builder: 313ms
textarea: 1187ms

Wist niet dat textboxen in C# zo sloom zijn

Of Stringbuilders in Java zo sloom

[momania]

Woy schreef op dinsdag 06 oktober 2009 @ 09:43:
[...]

Of Stringbuilders in Java zo sloom

Zonder de line separator, die Rob vergeten is, is het al iets sneller: 78ms

[Woy]

momania schreef op dinsdag 06 oktober 2009 @ 09:47:
[...]

Zonder de line separator, die Rob vergeten is, is het al iets sneller: 78ms

Rob doet ook een AppendLine, dus een line seperator is niet nodig

[momania]

[ Voor 11% gewijzigd door momania op 06-10-2009 09:53 ]

[roy-t]

Krijg je niet allemaal crossthread exceptions als je een swingworker gebruikt om de text te updaten? Of wordt dit uiteindelijk toch nog per regel geinvoked op het main thread? (Nog niet gezien dat iemand een swingworker gemaakt heeft, dus deze er even tussendoor).

[Woy]

roy-t schreef op dinsdag 06 oktober 2009 @ 10:46:
Krijg je niet allemaal crossthread exceptions als je een swingworker gebruikt om de text te updaten? Of wordt dit uiteindelijk toch nog per regel geinvoked op het main thread? (Nog niet gezien dat iemand een swingworker gemaakt heeft, dus deze er even tussendoor).

Dat was inderdaad ook iets wat ik me afvroeg. In veel GUI frameworks mag je inderdaad geen wijzigingen op de GUI elementen maken op een andere thread dan de GUI thread. Nu weet ik niet hoe dat in Swing zit, maar grote kans dat je daar ook rekening mee moet houden.

[RobIII]

Daarom zie ik ook heel het gedoe met, en de overhead van, een aparte thread niet. Behalve dat je code om zoiets triviaals veel foutgevoeliger wordt is het volgens mij complete overkill.

[momania]

roy-t schreef op dinsdag 06 oktober 2009 @ 10:46:
Krijg je niet allemaal crossthread exceptions als je een swingworker gebruikt om de text te updaten? Of wordt dit uiteindelijk toch nog per regel geinvoked op het main thread? (Nog niet gezien dat iemand een swingworker gemaakt heeft, dus deze er even tussendoor).

Nope, die crossthread exceptions (ofwel: concurrent modification exceptions) krijg je niet als je de swingworkers correct gebruikt.

De swingworker heeft 2 core methodes die je kan overriden: 'doInBackground()' en 'done()'
'doInBackground()' Wordt uitgevoerd in een managed threadpool en dat is dus de plek om je zware werk te offloaden.
Wil je gui updates doen nadat je werk klaar is, dan doe je dat via de 'done()' methode. Deze wordt uitgevoerd op de normale event dispatch thread en komt dus netjes in een queue van gui updates.

Wil je toch tijdens een background task tussendoor je gui updaten, doe je dat via 'SwingUtilities.invokeLater(Runnable doRun)'
Dat is de manier om direct iets op de event dispatcher te queuen.

Nogmaals: standaard code uitvoer in swing wordt altijd op de event dispatch thread uitgevoerd en blokkeert dus alle gui updates tot de code klaar is. (totale blokkade dus)

[ Voor 7% gewijzigd door momania op 06-10-2009 11:04 ]

[Twazerty]

ik zit een beetje met hetzelfde probleem. Dit is wat ik tot nu toe te weten ben gekomen is dit:
Je wilt het appenden op een jtextarea maar 1x doen!!! een jTextArea is enorm traag!

Dit is wat je het beste kan doen:

Java:

StringBuffer sb = new StringBuffer();
for(int i = 1; i < 99999; i++)
{
  sb.append(i+ "\n");
}
jTextArea1.append(sb.toString());

Bovenstaande code gaat waanzinnig snel. Als je iedere keer een append doet op je TextArea dan is hij enorm traag. Je String moet namelijk telkens opniew opgebouwd worden. En elke string die je toevoegd word steeds trager. Ik zit hier dus met zo'n 600-duizend tot 10 miljoen regels. Het tekenen in de jTextArea duurt langer als het creeren van de StringBuffer.

Het open van een tekstfile van 100MB en vervolgens wegschrijven in het panel duurt zo'n 15 seconden. Het telkens appenden van een string op een jTextArea bij een tekstfile van 10MB duurt een slordige 2 minuten.

Het probleem waar ik dus tegenaan loop is dat mijn GUI dus mooi een tijdje blijft hangen. (Net zoals Notepad)
Wellicht dat ik het zo laat. (Openen van de 100MB tekstfile duurt in notepad zo'n 40 seconden )


Edit: Als je de StringBuffer een begingrootte heeft kun je nog wat extra performance eruit persen. Ofwel:
StringBuffer sb = new StringBuffer(18000000); //array van 18000000 tekens
Een StringBuilder is in veel gevallen trager als een StringBuffer heb ik gemerkt.
Ook moet je dit niet doen:

Java:

String s = "";
for(int i = 1; i < 99999; i++)
{
  s += i + "\n";
}
jTextArea1.append(s);

Dat is ook enorm traag.

[ Voor 15% gewijzigd door Twazerty op 06-10-2009 11:22 ]

[RobIII]

^^ En dan heeft een aparte thread dus wél nut (los van de vraag of het nuttig is om 10 miljoen regels in een textarea te mikkeren...). Als overigens de .setText (of .append of whatever) alsnog 15 seconden nodig heeft om z'n (interne) werk te doen schiet je nog steeds geen fluit op met een aparte thread.

Twazerty schreef op dinsdag 06 oktober 2009 @ 11:18:
Ook moet je dit niet doen:

Dat is ook enorm traag.

Nogal wiedes. En StringBuilders/Buffers zijn er natuurlijk niet voor niets

[ Voor 66% gewijzigd door RobIII op 06-10-2009 11:25 ]

[Twazerty]

RobIII schreef op dinsdag 06 oktober 2009 @ 11:21:
^^ En dan heeft een aparte thread dus wél nut (los van de vraag of het nuttig is om 10 miljoen regels in een textarea te mikkeren...)

Het enigste probleem wat ik dus zie:
Waarom zou je dat willen? Op deze manier word je input gewoon geblokked. Je weet dat je niks kunt en mag doen. Enigste reden die ik nu heb is: Een progressbar met een indicatie dat hij bezig is.

Daar had ik gisteren nog geen oplossing voor. In Threads laten lopen werd een ramp. Nu nog een Worker proberen. Kijken of ik daar verder mee kom.

Ben bezig met een uitgebreidde kladblok versie die je hele filesystem in kan lezen. C: is dan makkelijk 600-duizend regels.

[RobIII]

Twazerty schreef op dinsdag 06 oktober 2009 @ 11:27:
Ben bezig met een uitgebreidde kladblok versie die je hele filesystem in kan lezen. C: is dan makkelijk 600-duizend regels.

Maar waarom zou je die meuk van-voor-tot-achter in een textarea willen mikkeren? Daar zijn toch vele beter alternatieven voor? Al laad je on the fly het deel (offset) wat op dat moment in je viewport staat. Is oneindig veel sneller en met een paar regels net zo goed te maken.

[momania]

Ok, even quick and dirty hoe je in Swing vanaf een GUI processen hoort te starten met eventuele tussentijdse updates, etc, etc.

Java:

        final JTextArea textArea = new JTextArea();
        final JProgressBar progressBar = new JProgressBar();
        SwingWorker<String, String> worker = new SwingWorker<String, String>() {
            @Override
            protected String doInBackground() throws Exception {
                // background shizzle
                StringBuffer sb = new StringBuffer();
                for (int i = 1; i < 99999; i++) {
                    sb.append(i).append("\n");
                    if (i % 1000 == 0) {
                        // publish tussentijdse updates
                        publish(sb.toString());
                        // set progress van deze worker
                        // een progress bar kan dus 'luisteren' naar updates van deze progress
                        setProgress((int)(i*0.001));
                    }
                }
                return sb.toString();
            }

            @Override
            protected void process(List<String> chunks) {
                // process the tussentijdse udpates and update gui
                // dit wordt ook netjes op de event dispatcher thread uitgevoerd
                for (String chunk : chunks) {
                    textArea.append(chunk);
                }
            }

            @Override
            protected void done() {
                // klaar met processen, update the gui
                try {
                    textArea.setText(get());
                } catch (Exception ignore) {
                }
            }
        };
        worker.addPropertyChangeListener(new PropertyChangeListenerProxy("progress", new PropertyChangeListener() {
            @Override
            public void propertyChange(PropertyChangeEvent evt) {
                progressBar.setValue((Integer) evt.getNewValue());
                // progressbar updates hier
            }
        }));

        worker.execute();

Ja, voor sommige zaken is dit overkill, maar voor echt lang lopende background processen is dit wel de manier om het te doen.

[_Noldy]

RobIII schreef op dinsdag 06 oktober 2009 @ 11:40:
[...]

Maar waarom zou je die meuk van-voor-tot-achter in een textarea willen mikkeren? Daar zijn toch vele beter alternatieven voor? Al laad je on the fly het deel (offset) wat op dat moment in je viewport staat. Is oneindig veel sneller en met een paar regels net zo goed te maken.

Eens. Je wil geen 600 000 regels in een textarea mikken. Dat is vragen om een hangend systeem. Met name als je het met append gaat doen. Op elk onderdeel van JTextArea etc binnen Swing heb je de paint() methode die alles voor je opnieuw gaat maken wanneer je iets wijzigt. Dus ook als je het in Threads gaat zetten moet je je afvragen of je dat echt wil.

*offtopic: Misschien is het beter die 600 000 regels uit te printen op je printer en er een mooi boek van te maken.

[Twazerty]

_Noldy schreef op dinsdag 06 oktober 2009 @ 13:32:
[...]


Eens. Je wil geen 600 000 regels in een textarea mikken. Dat is vragen om een hangend systeem. Met name als je het met append gaat doen. Op elk onderdeel van JTextArea etc binnen Swing heb je de paint() methode die alles voor je opnieuw gaat maken wanneer je iets wijzigt. Dus ook als je het in Threads gaat zetten moet je je afvragen of je dat echt wil.

*offtopic: Misschien is het beter die 600 000 regels uit te printen op je printer en er een mooi boek van te maken.

600000 regels is niet de bedoeling maar wel mogelijk. Programma moet er wel tegen kunnen zeg maar. Voornamelijke doel is dat je een gedeelte van je filesystem inleest en er iets mee doet. Bv even je filmlijst in een text bestandje knikkeren. (Recursief mappen doorlopen ed) Of even een lijst maken van al je albums. (Alleen folders lezen) Een app dat vanalles kan met je files. Als mensen toch hun hele C tree in willen lezen ga ik direct naar een file schrijven. Zonder weergave. Maar 50000 regels is geen uitzondering. Bv een muziekcollectie komt daar makkelijk aan.

Alleen loop nog tegen memory problemen aan. Windows clipboard die geen 60MB plain text pakt (Vanuit java naar windows clipboard schrijven) en gewoon java VM ram problemen. Word volgens mij door jTextArea veroorzaakt. Ga nog wel allerlei oplossingen bedenken. (Max aantal regels inlezen ed) maar voor nu:
Ik doe het omdat het kan Wil graag de problemen tegenkomen. (Ben nog student)

Edit: het editen binnen een jTextArea gaat overigens wel snel ondanks dat er 1.2 miljoen regels in staan nu als je de wrap maar uit hebt staan. Die zorgt voor trage repaints.

[ Voor 5% gewijzigd door Twazerty op 06-10-2009 15:16 ]

[roy-t]

momania schreef op dinsdag 06 oktober 2009 @ 11:02:
[...]

Nope, die crossthread exceptions (ofwel: concurrent modification exceptions) krijg je niet als je de swingworkers correct gebruikt.

De swingworker heeft 2 core methodes die je kan overriden: 'doInBackground()' en 'done()'
'doInBackground()' Wordt uitgevoerd in een managed threadpool en dat is dus de plek om je zware werk te offloaden.
Wil je gui updates doen nadat je werk klaar is, dan doe je dat via de 'done()' methode. Deze wordt uitgevoerd op de normale event dispatch thread en komt dus netjes in een queue van gui updates.

Wil je toch tijdens een background task tussendoor je gui updaten, doe je dat via 'SwingUtilities.invokeLater(Runnable doRun)'
Dat is de manier om direct iets op de event dispatcher te queuen.

Nogmaals: standaard code uitvoer in swing wordt altijd op de event dispatch thread uitgevoerd en blokkeert dus alle gui updates tot de code klaar is. (totale blokkade dus)

Thanks voor deze uitleg, hoop dat de TS er ook wat aan heeft. Handig dat die swingworkers dus zelf voor je invoken op het main thread (bij done).