 |
Author |
Topic: diabling multi-threading in mouse and kbd events (Read 405 times) |
|
arielm
|
diabling multi-threading in mouse and kbd events
« on: Sep 4th, 2003, 3:35pm » |
|
as an extension to this discussion:
http://proce55ing.net/discourse/yabb/board_Syntax_action_displa_y_num_1062622554.html
from a lingo/actionscript/dhtml user point of view, and as well as from a total beginner's point of view, i think it's counter intuitive and prone to current and future problems to have a situation where the code inside mouse and keyboards events is not running in the same "thread" as the code in loop().
as an example, the following Code:
void setup()
{
size(500, 500);
}
void loop()
{
// things...
}
void mouseMoved()
{
fill(0, 0, 0);
ellipse(mouseX, mouseY, 50, 50);
}
|
|
is currently producing a terrible flickering instead of a more predictable/intuitive behavior (simply a circle being drawn, following the mouse...)
maybe all this has been already discussed, and the current way of doing is the best technical compromise or is there a place to look for alternatives
e.g. continuing to internally grab keyboard input asynchronously, but exposing the data as a buffer instead of a single variable, and having Bagel call the user's keyPress method on "idle" (i.e. between frames)...
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
 
|
Re: diabling multi-threading in mouse and kbd even
« Reply #1 on: Sep 4th, 2003, 5:30pm » |
|
wouldn't it already be working that way with the new api to have users call background() manually wherever they want in each loop()?
|
|
|
|
|
fry
|
Re: diabling multi-threading in mouse and kbd even
« Reply #2 on: Sep 4th, 2003, 6:18pm » |
|
yes, this is one of the issues solved by recent changes i've made to how background() will work in 60.
background() will actually clear the background (rather than just setting a background color to be used at the beginning of the next loop()), and mouse events will be queued to run after loop has exited (moved/dragged are taken care of, i'll get pressed/released/clicked in there too).
|
|
|
|
|
arielm
|
Re: diabling multi-threading in mouse and kbd even
« Reply #3 on: Sep 4th, 2003, 9:11pm » |
|
okay, so to summarize:
- the background won't be automatically cleared just before loop() is executed, anymore.
- instead, the user will have the freedom to insert a manual background() statement that will clear the background (btw, any drawing operation that will appear before that statement in the code will never be visible, so it's likely that it will always be at the beginning of loop, no?)
- concerning events, it's still not clear to me how it will work:
if the events are "queued" (and not interupting the loop thread anymore), does it mean that, say, if someone is typing fast, there could be n consecutive calls to the user's keyPressed method?
and if so, when exactly those queued event are going to be "delivered"?
just after loop and before the pixel buffer is flush or anytime during the "idle" period between frames?
i guess this question is relevant, in order to know if it will be possible to "draw things from within an event user method"...
(sorry to be so question-attackfull on this one... i'm just in the middle of programming something similar for a forthcoming online-javascript-pseudo-processing-environment, and i'm facing the same kind of issues!)
|
Ariel Malka | www.chronotext.org
|
|
|
arielm
|
Re: diabling multi-threading in mouse and kbd even
« Reply #4 on: Sep 5th, 2003, 12:17am » |
|
hmm, second thought...
i "cancel" this software suggestion of mine, since i realize now how much it's an advantage (in comparison with lingo/actionscript/dhtml) to have multi-threaded mouse and keyboard events.
and in term of what's more intuitive: afterall, i guess it is intuitive (at least for beginners, non influenced with the 3 mentioned environments):
- to consider that, say, a mouseMoved event will interupt the current code in loop...
- and also that the mouseX/pmouseX variables are always reflecting an exact state (rather than some frozen value...)
so my only suggestion would be to add in the documentation that it's not recommanded to perform drawing operations within mouseMoved & co (when using background clearing)
bglpppl
|
Ariel Malka | www.chronotext.org
|
|
|
fry
|
Re: diabling multi-threading in mouse and kbd even
« Reply #5 on: Sep 5th, 2003, 1:01am » |
|
right.. we'll document how just mouseMoved() et al, the ones with no parameters, work. those are p5-specific and will be queued up to be unwound just at the end of loop().
the people that want threaded interaction can override the java methods: "public void mousePressed(Event e)" which will give them full control. this is a much more advanced concept, but we have it waiting for ppl underneath.
the idea is that the vast majority of people will be more confused about the multithreading (why is my stuff flickering when i draw in mousePressed) and the smaller group of more advanced people will wonder why that can't do full multithreading.
of course, there's also update() mode (a third drawing mode) coming, where you'll have to trigger the update events yourself. which leads to better threaded operation (and the queue will prolly be disabled).
|
|
|
|
|
arielm
|
Re: diabling multi-threading in mouse and kbd even
« Reply #6 on: Sep 9th, 2003, 12:19am » |
|
well, afterall... (i.e. it's not only me changing my mind all the time):
it seems that all this (trying to minimize the effects of multithreading between loop() and events-processing) does make sense in the forthcoming versions of processing!
so ben, you're invited to tell us more about how things will work, when you have time 
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
|
Re: diabling multi-threading in mouse and kbd even
« Reply #7 on: Sep 10th, 2003, 5:01pm » |
|
so, umm, arielm - is it time for an art-imitates-art round?
sketches designed to explore, critic and explain the framework of p5?
white-on-white sketches?
|
|
|
|
|
|
