Best approach to registering all elements touched

Android Processing

mfmc.dev

Best approach to registering all elements touched

in Android Processing • 2 months ago

I have a grid of ellipses and I want to highlight the ellipses that have been on the path of a finger swiping over the screen. The code I'm using at the moment doesn't always highlight all ellipses (especially when swiping across the screen really fast). Does anyone have an idea of a more efficient way of approach this? or any ideas why not all ellipses touched get highlighted?

Code used:

boolean[][] checked = new boolean[5][5];
void setup() {
size(displayWidth, displayHeight);
ellipseMode(CENTER);
smooth();
noStroke();
frameRate(30);
}
void draw(){
background(255);
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
fill(0,100);
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
if (mousePressed && sqrt(sq((i*width/5-width/10)-mouseX) + sq((height/8+j*height/8)-mouseY)) < width/7) {
checked[i-1][j-1]=true;
}
if (checked[i-1][j-1]) {
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
}
}
}
}
void mouseReleased() {
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
checked[i-1][j-1]=false;
}
}
}

Thanks!

Replies(12)

GoToLoop

Re: Best approach to registering all elements touched

2 months ago

Perhaps mouseMoved() or mouseDragged() can be more efficient at detecting all movements?

mfmc.dev

Re: Re: Best approach to registering all elements touched

2 months ago

Thanks, had a quick try, mouseDragged seems to perform a lot better!

Question though, and maybe this is obvious, but I don't get why this top version of the code is a lot slower than the bottom version (I figured to bottom would be slower as I'm adding another 2 for loops..)

boolean[][] checked = new boolean[5][5];
boolean drag;
void setup() {
size(displayWidth, displayHeight);
ellipseMode(CENTER);
smooth();
noStroke();
frameRate(30);
}
void draw(){
background(255);
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
fill(0,100);
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
if (drag && sqrt(sq((i*width/5-width/10)-mouseX) + sq((height/8+j*height/8)-mouseY)) < width/7) {
checked[i-1][j-1]=true;
}
if (checked[i-1][j-1]) {
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
}
}
}
}
void mouseReleased() {
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
checked[i-1][j-1]=false;
}
}
drag=false;
}
void mouseDragged(){
drag=true;
}

boolean[][] checked = new boolean[5][5];
void setup() {
size(displayWidth, displayHeight);
ellipseMode(CENTER);
smooth();
noStroke();
frameRate(30);
}
void draw(){
background(255);
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
fill(0,100);
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
if (checked[i-1][j-1]) {
ellipse(i*width/5-width/10,height/8+j*height/8,width/7,width/7);
}
}
}
}
void mouseReleased() {
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
checked[i-1][j-1]=false;
}
}
}
void mouseDragged(){
for (int i=1; i<=5; i++){
for (int j=1; j<=5; j++){
if (sqrt(sq((i*width/5-width/10)-mouseX) + sq((height/8+j*height/8)-mouseY)) < width/7) {
checked[i-1][j-1]=true;
}
}
}
}

Thanks for your help though, mouseDragged seems to do the trick!

mfmc.dev

Re: Best approach to registering all elements touched

2 months ago

Also, out of interest, would anyone approach this in a different way? Still keen to get the fastest possible response from the Android device, so want to make sure I'm using the most efficient approach!

GoToLoop

Re: Best approach to registering all elements touched

2 months ago

I did some optimizations. Mostly pre-calculation into variables.
Check it out:

/** 
 * Touching Selection (v2.03)
 * by mfmc.dev (2013/Aug)
 * mod GoToLoop
 * 
 * http://forum.processing.org/topic/best-approach-to-registering-all-elements-touched
 */

import java.util.Arrays;

final static color LIGHTER = 0100 << 030, DARKER = 0200 << 030;
final static short ROWS = 6, COLS = 5, FPS = 30;
final static boolean[][] isSelected = new boolean[ROWS][COLS];

int diam, rad, w5, w10, h8, h16;

void setup() {
  //size(displayWidth, displayHeight);
  size(800, 600);

  frameRate(FPS);
  noLoop();
  noStroke();
  smooth();
  ellipseMode(CENTER);

  diam = width/7;
  rad  = diam>>1;

  w5  = width/5;
  w10 = width/10;
  h8  = height>>3;
  h16 = height>>4;
}

void draw() {
  background(-1);

  for (int i=1; i<=ROWS; i++)   for (int j=0; j!=COLS;) {
    fill(isSelected[i-1][j++] ? DARKER : LIGHTER);
    ellipse(j*w5 - w10, i*h8 + h16, diam, diam);
  }
}

void mouseReleased() {
  for (int i=0; i!=ROWS; Arrays.fill(isSelected[i++], false));
  redraw();
}

void mouseDragged() {
  for (int i=1; i<=ROWS; i++)  for (int j=1; j<=COLS; j++)
    if (dist(j*w5 - w10, i*h8 + h16, mouseX, mouseY) < rad) {
      isSelected[i-1][j-1] = true;
      redraw();
      return;
    }
}

dimkir

Re: Best approach to registering all elements touched

2 months ago

Your "second" code doesn't run faster, but rather creates "illusion" of running faster. Because in the first code you only check your mouse for changing position about 30 times per second (let's assume your framerate is 30fps). Whereas in the second code you can be receiving event informing you about change of mouse position maybe even up to 1000 times per second (for example when you swipe your finger really quickly from left to right, changing X coordinate from 10 to 1010).

When processing sketch runs, you will have two threads:

the drawing thread
the event thread

The "drawing thread" does only single task: it calls draw() maximum 30 times per second (at 30 fps)

EDIT:

wherease the event thread dedicates itself 100% to listening whether an input even occurs and once there is one: to call appropriate method (eg. mouseDragged() or mouseMoved()). This is why mouseMoved() may be called up to 1000 times per second, depending on how sensitive/responsive your hardware is.

As a rule of thumb, you (in advanced Processing development) should never use mouseX or mouseY inside of draw(), but either process them in mouseXXXX() methods. Or buffer them when mouseXXXX() event is called and then process buffer inside of draw().

If you use mouseX and mouseY inside of draw you will also be "frame-dependent" so your lines will be very jagged.

Here's the sketch which illustrates "queing of mouse events". When I run this sketch at my laptop, at 60 frames per second, i always have at least 2 mouse movements in the queue. If you try setting lower FPS, then you may notice that you may queue even 20 mouse events between the frames.

ps. you may want to remove drawing image as background, for sketch to run:

/**
* This sketch uses queing of mouse events, so that
* we're able to draw SMOOTHLY with the mouse on the screen
* and also be frame indepedent.
*/
// i think thousand queued mouse events between two frames would be enough
final int MAX_QUEUED_MOUSE_EVENTS = 1000;
int[] queueOfMouseX = new int[MAX_QUEUED_MOUSE_EVENTS];
int[] queueOfMouseY = new int[MAX_QUEUED_MOUSE_EVENTS];
int queuedEventsCount = 0;
PImage bg;
int lastX, lastY;
void setup(){
size(displayWidth,displayHeight );
bg = loadImage("small_example.png");
//frameRate(2);
image(bg, 0, 0);
}
void draw(){
drawQueuedMouseEvents();
// int dx = (mouseX - pmouseX);
// int dy = (mouseY - pmouseY);
// println("DRAW mouse moved by " + dx + " " + dy) ;
}
void mouseDragged(){
//println("MOUSE_MOVED by " + (mouseX - lastX) + " " + (mouseY - lastY) + " button: "+ mouseButton);
lastX = mouseX;
lastY = mouseY;
if ( mousePressed ){
saveMouseEvent(mouseX, mouseY);
//println("Saving mouse event");
}
}
void mousePressed(){
// if ( mouseButton == RIGHT ){
// background(128);
// }
}
void saveMouseEvent(int mx, int my){
if ( queuedEventsCount == MAX_QUEUED_MOUSE_EVENTS ){
throw new RuntimeException("Some error in logic. cannot be between frames so many mouse events and movements");
}
queueOfMouseX[queuedEventsCount] = mx;
queueOfMouseY[queuedEventsCount] = my;
queuedEventsCount++;
}
void drawQueuedMouseEvents(){
println("Queued mouse event count: " + queuedEventsCount );
for(int i = 0 ; i < queuedEventsCount ; i++){
drawMouse(queueOfMouseX[i], queueOfMouseY[i]);
}
queuedEventsCount = 0;
}
void mouseReleased(){
// reset draw mouse as if we start drawing from scratch.
prevMouseX = -1;
prevMouseY = -1;
}
float prevMouseX = -1;
float prevMouseY = -1;
void drawMouse(int xx, int yy){
strokeWeight(3);
if ( prevMouseX < 0 ){ // we haven't actually run this yet.
ellipse(xx, yy, 8, 8);
}
else{
line(prevMouseX, prevMouseY, xx, yy);
}
prevMouseX = xx;
prevMouseY = yy;
}

GoToLoop

Re: Best approach to registering all elements touched

2 months ago

My further attempts to squeeze more performance:

/** 
 * Touching Selection (v2.13)
 * by mfmc.dev (2013/Aug)
 * mod GoToLoop
 * 
 * http://forum.processing.org/topic/best-approach-to-registering-all-elements-touched
 */

import java.util.Arrays;

final static color LIGHTER = 0100 << 030, DARKER = 0200 << 030;
final static short ROWS = 6, COLS = 5, FPS = 30;
final static boolean[][] isSelected = new boolean[ROWS][COLS];

int diam, rad, w5, w10, h8, h16, h32;

void setup() {
  //size(displayWidth, displayHeight);
  size(800, 600);

  frameRate(FPS);
  noLoop();
  noStroke();
  smooth();
  ellipseMode(CENTER);

  diam = width/7;
  rad  = diam>>1;

  w5  = width/5;
  w10 = width/10;
  h8  = height>>3;
  h16 = height>>4;
  h32 = height>>5;
}

void draw() {
  background(-1);

  for (int i=1; i<=ROWS; i++)   for (int j=0; j!=COLS;) {
    fill(isSelected[i-1][j++] ? DARKER : LIGHTER);
    ellipse(j*w5 - w10, i*h8 + h16, diam, diam);
  }
}

void mouseReleased() {
  for (int i=0; i!=ROWS; Arrays.fill(isSelected[i++], false));
  redraw();
}

void mouseDragged() {
  final int mx = mouseX/(w5 - w10)/2 + 1;
  final int my = mouseY/(h8 + h8) + 1;
  //final int my = mouseY/(h8 + h32) + 1;
  print(mx + ", " + my + "\t");

  //if (mx > COLS | my > ROWS)  return;

  /*
  if (dist(mx*w5 - w10, my*h8 + h16, mouseX, mouseY) < rad) {
   isSelected[my-1][mx-1] = true;
   redraw();
   return;
   }
   */

  for (int i=my; i<=ROWS; i++)  for (int j=mx; j<=COLS; j++)
    if (dist(j*w5 - w10, i*h8 + h16, mouseX, mouseY) < rad) {
      isSelected[i-1][j-1] = true;
      redraw();
      return;
    }
}

dimkir

Re: Best approach to registering all elements touched

2 months ago

why use

  h8  = height>>3;
  h16 = height>>4;
  h32 = height>>5;

instead of

  h8  = height/8;
  h16 = height/16;
  h32 = height/32;

isn't the last one clearer for majority of this forum audiences?
;)

dimkir

Re: Best approach to registering all elements touched

1 month ago

and correct me if I am wrong, but majority of people I know use decimal system. Some people use hexadecimal.

Maybe once per 6month it's useful to think in binary system.

But OCTAL?????

final static color LIGHTER = 0100 << 030, DARKER = 0200 << 030;

You can call me stupid, but for the last 5 minutes I was looking at this

line of code and couldn't  figure out what it's was doing. So then I took paper and pen

and started investigating.

Attempt 1

First I had to convert 0100 to decimal to try to guess what it means

(which turned out to be 64).

Now i have converted 030 from octal to decimal and it turned out to be 24:

So now I can make the original operation

                
                 color LIGHTER = 0100 << 030;
                
a bit more human-readable (see below), but still it doesn't really make me understand what's happening.
                 
                  color LIGHTER = 64 << 24; 
                 

So let's go even further. As programmers know, that 64 << N is an operation known as "Arithmetic left shift" 
and it is synonymous to multiplying 64 by (2 to power N). So I can actually translate this line of code even
further:
                 
                  color LIGHTER = 64 * (2 to the power 24);
                 
equal to
                 
                  color LIGHTER = 64 * 16 777 216; // 16 million smth
                 
By now I realize that this multiplication doesn't make much sense. And that my current approach has 
reached dead-end. It's not giving me understanding, and I have to start investigation from scratch.


Attempt 2:
So now I will try to represent the numbers as hex values and try to visualize them by drawing them
 in my sketchpad.

So first thing I have noticed is that 0100 (in octal) is 64 in decimal and 40 in hexadecimal. 
Let's think of how Java represents numbers: types int or color  are represented as 4 bytes:

So now we can take the original line:

color LIGHTER = 0100 << 030

and rewrite it in more convenient for understanding format (but it still doesn't make things 
super clear):
color LIGHTER = 40(hex)  << 24(decimal)

As you have noticed I continue thinking about the second argument (24) as decimal, as it's more convenient.

So what does this 40 (hex) << 24 actually do? This is "shift left" binary artihmetics operator, 
which will shift all bytes to the left by 24 bits. 
If we think of it in hexadecimal, then what happens is that our 40 will move to the very left part of the integer.



so the result of the "shift left" operation would be that the 40 being on the very left tip of the integer:


So now we're done with "decyphering" this mysterious line. All it does, just sets
 the highest byte of the integer to 40hex.

But now let's think how does it influence our drawing?
Remember that colors in memory are represented with 4 bytes:

                 
                  A - "alpha" or transparency
                  R - for red "intensity" of the color
                  G - for green "intensity" of the color
                  B - for blue "intensity" of the color
                 

So by setting the highest byte of the color to 40hex, what we actually do  is:
                 
                  we set transparency byte to 40hex and all color "intensities" to 0
                 
                 
                  which is same as
                 
                 
                  
                   we set transparency byte to 64 (decimal) and all color "intensities" to 0
                  
                 
                 
                  

                 
                 
                  which is same as 
                 
                 
                  
                   we set transparency to 64 and the color to BLACK
                  
                 
                 
                  

                 
                 
                  which is equal to Processing command
                 
                 
                  
                   LIGHTER = color(0,0,0,64);
                  
                 
                 
                  

                 
                 
                  which is equal to processing command:
                 
                 
                  
                   LIGHTER = color(0,64);

And when you read the ^^^^^ above line, it only takes half a second to realize that we just set

the transparency to 25%.

So just by replacing:

final static color LIGHTER = 0100 << 030, DARKER = 0200 << 030;
with this:

final static color LIGHTER = color(0, 64);
final static color DARKER = color(0, 128);

would have:

a) saved like 5 minutes of time on figuring out what's actually happening there

b) allowed for easier modification, eg. change of color would be really easy:

just replace it with:

final static color LIGHTER = color(#FF0000, 64); // red
final static color DARKER = color(#FF0000, 128); // red

c) If you would have changed color mode to HSB in future life of the sketch via colorMode(HSB, 100); 
it would be really easy to find all places where color is set by searching sketch for substrings containing
"#" or "color("

In general I understand that for a professional programmer this line:
final static color LIGHTER = 0100 << 030, DARKER = 0200 << 030;
may be self explanatory. But as far as I understand processing is for beginners and for introduction to
 programming. 
So IMHO writing code as simple as possible would allow more people to read it and 
understand different approaches. Whereas "professional" code IMHO may scare people away 
from reading the code.

GoToLoop

Re: Best approach to registering all elements touched

1 month ago

I had no intention of folks hammering their heads over it. At least not that much. :D
Focus should be aimed at the meaning of the constant labels themselves -> LIGHTER & DARKER.
Not at its "decimal" or "hexadecimal" values. Which doesn't make much sense anyways!

If any1 wanted a diff. value for them; they could change that very easily
by replacing 0100 << 030 to something else. Anyways, both of those constants are of color data-type.
As long as LIGHTER remains being a more transparent color, and DARKER a more opaque one, of course.

That's why I tend to use constants in my examples as much as possible:
To make easier to modify program's parameters at 1 place.
Rather than chasing them around somewhere else!

As for the reason why I've picked octal over decimal & hexadecimal in this case and similar, lemme explain myself:
Data-type color is comprised of 4 octet channels: A, R, G, B. Each 1 varies from 0 to 255. That is, 1 byte.
Let's say we decide to divide 256/4, we end up w/ 4 intensity levels for each of them. That is, 25% or 1 quarter.

Decimal	0	64	128	192	256 - 1
Hexa	0x0	0x40	0x80	0xC0	0x100 - 1
Octal	00	0100	0200	0300	0400 - 1
Percentage	0%	25%	50%	75%	100%
Fractional	none	quarter	half	three/fourth	whole

In my eyes, that octal sequence is more aesthetically pleasing than the others!
So, when I see 0300, I interpret it as 75% or 3/4 of a channel intensity!
In my mind, I don't try to convert it into its decimal value or anything else!

The same applies to the bit-shift value.
0100 in itself would apply to the B (blue) channel only.
To change it to count as the A (alpha) channel, we have to left-shift it 3 bytes.
Each byte or octet is 8 in both decimal and hexa. But it's 010 in octal.
So, 3 bytes would mean:

decimal -> 8*3 = 24 bits.
hexa -> 0x8 * 3 = 0x18 bits.
octal -> 010 * 3 = 030 bits.

Again, octal generates a more pleasant sequence for octet bit-shifting:
010, 020, 030...

Compare that to decimal -> 8, 16, 24... and hexa -> 0x8, 0x10, 0x18...

Well. That's my excuse to use octal for some specific cases, like colors! ^_^

GoToLoop

Re: Best approach to registering all elements touched

1 month ago

Warning:

Neither final static color LIGHTER = color(0, 64);
nor final static color DARKER = color(0, 128);

can be declared as static. B/c method color() isn't static itself.
And it's unable to generate a known compile-time constant value.
Rather, a merely run-time value.

You can however use the 1s below for a true compile-time constant:

final static color LIGHTER = 0x40000000;
final static color DARKER = 0x80000000;

In place of 0100 << 030; & 0200 << 030;

dimkir

Re: Best approach to registering all elements touched

1 month ago

Again, octal generates a more pleasant sequence for octet bit-shifting:
010, 020, 030...

Yeah. It indeed looks very convenient. I only realized it after :D haha

mfmc.dev

Re: Best approach to registering all elements touched

1 month ago

Thanks guys! This looks awesome, I'm away at the moment, but I'm going to do some more experimenting with this over the weekend, will let you know where I end up! Either way, I'm going to have to read up on octet bit-shifting :)

Top Reply