Threads and VST GUI

General JUCE discussion
1

I wrote a small VST plugin (based on the AudioPlugin example).
Everything is fine, it’s not really an Audio plugin yet, it will be for now it’s a chat thingy screenshot

the problem is that the networking thing is done in a seperate thread and should not block, however if u run it in FLStudio like i do, you can see the FL stopping for the time the thread is doing it’s network stuff, here is the worker tab

void Worker::run ()
{
	// do the bartman
	Url = new URL ("http://www.fruityart.org/chat.php");
	
	if (threadShouldExit())
		return;

	InputStream *stream = Url->createInputStream(false);
	
	if (threadShouldExit())
		return;
	
	buf = stream->readEntireStreamAsString();
	
	delete stream;
	delete Url;

	return;
}

the buf point to a variable in the other class where i do the parsing and all like so:

void HttpClient::timerCallback ()
{	
	if (worker->buf.length () != 0)
	{
		parser (worker->buf);
	}
	
	worker->startThread();
	startTimer(2000);
}

why is this blocking the MAIN program (should be blocking the GUI of the plugin), i noticed that when the plugin is hidden there is no blocking.

2

There’s nothing in the thread that would interfere with the UI or anything else at all, really, so that’s very odd.

The timer callback will happen on the message thread, so that will block the UI - are you sure it’s not in there that you’re causing the hold-up?

3

the whole httpclient class looks like this



HttpClient::HttpClient ()
{
	worker = new Worker();
	//worker->addChangeListener (this);
}

void HttpClient::timerCallback ()
{	
	if (worker->buf.length () != 0)
	{
		parser (worker->buf);
	}
	
	worker->startThread();
	startTimer(2000);
}

HttpClient::~HttpClient ()
{
	delete worker;
}

void HttpClient::changeListenerCallback (void* objectThatHasChanged)
{
}


void HttpClient::parser (const String& str)
{
	int line_len=0, lines=0, i=0;
	
	outputBox->setText ("", false);
	
	for (i=0; i<=str.length (); i++)
	{
		if (str[i] == '\n')
		{
			outputLine (str.substring (i-line_len, i));
			line_len = 0;
		}
		else
			line_len++;
	}
}

void HttpClient::outputLine (const String& str)
{
	int nickEnd = str.indexOfChar (':');
	const String nick = str.substring (0, nickEnd);
	const String message= str.substring (nickEnd);
	
	outputBox->setColours (Colour (255, 0, 0));
	outputBox->insertTextAtCursor (nick);
	outputBox->setColours (Colour (12, 12, 12));
	outputBox->insertTextAtCursor (message + "\n");
}

the part that could be holding the GUI is the insertTextAtCursor () method, but is that that CPU intensive ? we’re not talking large amounts of text about 50 lines or so (the output from the serv is limited).

4

try not doing any work in the timer thread, and see if it still happens… or try not dong any work in the worker thread, etc.

5

k

right after i get home from work.

6

well now i know

void HttpClient::outputLine (const String& str)
{
	int nickEnd = str.indexOfChar (':');
	const String nick = str.substring (0, nickEnd);
	const String message= str.substring (nickEnd);
	
	outputBox->setColours (Colour (255, 0, 0));
	outputBox->insertTextAtCursor (nick);
	outputBox->setColours (Colour (12, 12, 12));
	outputBox->insertTextAtCursor (message + "\n");
}

this part makes the host application flicker.
Is this a very bad way to do it ? Should i implement some kind
of diff algorithm to only update wiith the difference of the current and the previous text ? Or maybe there is a much optimal way to do this ?

7

no, it’s a fair way of outputting text, and shouldn’t take too long. Remember the release build will go much faster than the when you’re debugging it.