[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Asynchronicity and docs
- To: sc-dev@xxxxxxxxxxxxxxxx
- Subject: Re: [sc-dev] Asynchronicity and docs
- From: "James Harkins" <jamshark70@xxxxxxxxx>
- Date: Thu, 18 Dec 2008 18:15:30 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=X6LghE9hyn6jhCaPycub7n+jIDXopoXWfN6vAPaQn+M=; b=EiWRBckqP7atDLi6kn8QWZNe+2gNpflshkfkTITIUI7rEGLmJMt1PXb1nKpi+bTUU4 M0ZGZsYfL7UhRJCJMjV3ouzNMbuG65a6h7SL0QmW/a54t3bGOOHlDKY2Wr+AgblDs3tc tw+uH3k746xBT/w13jfSyQO+g0IH9FUPbpjbc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=skkJVBvfEQHZoKWce2rdSa+QJhuxz3cuEmrpVx0Td00rRlLdqUZlwgnbC/LtvJWvRs kMID3WETzGRpp8Aky4kFC5HA7d1iPOM2nxlqPFeBZZcxmpe0XFgmXuIQW5aP3OFBCyqF B85Q+fDhAQMAx7cUu2htW6MpyQ5KvizNqhVpQ=
- In-reply-to: <494ABF5F.106@xxxxxxxx>
- List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
- References: <494ABF5F.106@xxxxxxxx>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
On Thu, Dec 18, 2008 at 4:23 PM, jostM <sc3@xxxxxxxx> wrote:
> I adopted a section from the old GUI intro, which seems rather confusing
> to me. see below.
> Firstly, stringBounds in th SwingGUI kit is currently not asynchronous.
> It is calculated using a factor. Secondly, it seems to me that
> asynchronicity is a general point which concerns using the SwingOSC
> Server, and should perhaps be mentioned in separate section concerning
> the SwingGUI scheme. If something is really asynchronous, then you
> actually need to wait for a reponse before you continue, like with
> OSCResponderNode. (And indeed, the Swing kit uses OSCResponderNode
> transparently in its gui init classes).
>
> So I would prefer to leave this out here, and would ask someone with
> indepth knowledge of the swing library to write a paragraph about how to
> treat timing when using the swing kit.
Well, you never had precise control over gui update timing, with
neither cocoa nor swing.
stringBounds is really the only messed up case AFAIK. It uses a factor
now to avoid the issues with asynchronicity. It's a hack but the
alternative - forcing every use of stringBounds to be in a routine -
is worse in a lot of ways.
Calls to get gui properties are synchronous, even in swingosc, because
swing views keep client-side copies of all properties. As soon as a
property changes in the swing server, the client gets notified of the
change and updates the client-side info. So, aView.value can be
synchronous because there is no communication with the server *at the
time the user asks for the value* -- the server's value change was
communicated back to the client long ago.
Calls to change gui properties on the swingosc server are synchronous
within the client, though the actual update in Java is asynchronous.
But there is no reason for the client to worry about that.
I don't see this as a big issue. SwingOSC does a very good job of
making all this transparent to the user. stringBounds is the only
exceptional case I know of.
hjh
--
James Harkins /// dewdrop world
jamshark70@xxxxxxxxxxxxxxxxx
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/