dimX = centerX = width>>1; is a bit shift.

for example 

    int a = 5;        // binary: 0000000000000101
    int b = a << 3;   // binary: 0000000000101000, or 40 in decimal
    int c = b >> 3;   // binary: 0000000000000101, or back to 5 like we started with

Yes, GoToLoop likes to show off and confuse newbies with special tricks... (or just has his own special style of programming, to be kinder...)

width >> 1 is just width / 2
if (pointX > width | pointY < 0) is an inefficient equivalence to if (pointX > width || pointY < 0)
Inefficient because the version with || stops if the first test is true, while the version with | must check both tests.

BTW, pedroam, please, try and use better subject lines. As you can see in the URL, the subject was numbered because it is not unique! The line is unhelpful, not telling what is your exact problem. Imagine a forum where each topic is named "help me", "noob aboard", "please help me asap", etc.
Lot of people around are indeed newbies, and you are in the Programming Questions section, so we expect you to ask a question...
Something like "draw ellipses and oblique lines" (straight from your first message) would be more explicit.
It is easier to find back a topic when it has a unique and explicit subject.

thank you guys!

i'll follow your tips from now on PhiLho.

Inefficient because the version with || stops if the first test is true, while the version with | must check both tests.

That is true indeed. But in order to do that, there has to be a little overhead to create a code branch check for it!
Lazy evaluations are more complex than eager ones. In fact, bitwise operators are faster than other types!

For simple expressions, it's faster to evaluate each 1 of them, rather than setup a lazy branch check for each 1;
in hopes to get a short-circuiting outta 'em at some point!

Of course, if there's some operand which is a method call or a heavy calculation, we should always re-arrange the expression
as such that fast tests happen 1st, and those heavy ones can be avoided by short-circuit!

Here's a quick test I've made. Java is so good at optimizing that any gains are very insignificant! 
Nevertheless, it's still possible to verify that for expressions formed by simpler operands,
eager are faster than lazy! 

final static int ITERATIONS = 20000000, RAND = 10000;

void setup() {
  eagerTest(ITERATIONS >> 4);   // warm-ups
  lazyTest(ITERATIONS  >> 4);

  int timer = millis();
  println( eagerTest(ITERATIONS) ); // real eager test
  println( "Eager: " + (millis() - timer) );

  timer = millis();
  println( lazyTest(ITERATIONS) );  // real lazy test
  println( "Lazy: " + (millis() - timer) );

  exit();
}

int eagerTest(int ii) {
  float a, b, c, d, e, f, g, h;
  int counter = 0;

  for (int i = ii; i != 0; --i) {
    a = random(RAND);
    b = random(RAND);
    c = random(RAND);
    d = random(RAND);
    e = random(RAND);
    f = random(RAND);
    g = random(RAND);
    h = random(RAND);

    if (a < b & c > b | e == f & g != h)  ++counter;
  }

  return counter;
}

int lazyTest(int ii) {
  float a, b, c, d, e, f, g, h;
  int counter = 0;

  for (int i = ii; i != 0; --i) {
    a = random(RAND);
    b = random(RAND);
    c = random(RAND);
    d = random(RAND);
    e = random(RAND);
    f = random(RAND);
    g = random(RAND);
    h = random(RAND);

    if (a < b && c > b || e == f && g != h)  ++counter;
  }

  return counter;
}

" any gains are very insignificant!"
That's why you should drop your funny but useless and confusing optimizations: this is not C, even less assembly language.
In Java, general advice is to write in a readable way, for you and for the others, and to rely on the compiler to do the best optimizations. As the saying goes, optimize only when your program is too slow (or too memory hungry), "premature optimization is the root of all evil". (a slight exaggeration! )

Speed gain given by >> 1, | or usage of final / byte over int and such are generally void in a normal sketch, and you often get confused remarks by newbies looking at these odd constructs.
You are a valuable contributor, that's why I give this advice. Of course, you can ignore it, you are free, but it is too bad you reduce the interest of your good code with these distracting gimmicks.

You know when to use | vs. || for example (in a test like if (x != null && x.length() > 0), using & would be a disaster!), but most newbies would fall in the trap.
Likewise, using byte for a single variable isn't useful (can even be slower than a int!) in terms of memory gain, and some newbies might try to use them beyond 127.
And so on.

Just a friendly advice.

PS.: I forgot about the lazy vs. eager speed difference, your test is interesting.
But I was thinking in more general terms, where expressions are generally complex (eg. rect / rect intersections with intermediary computations, or method calls in the test). If you have to think ahead "is my test simple enough that a bitwise operator will be faster?", you just loose time and energy better spent on general program design.

although this maybe the wrong place to continue this discussion, i want to add something.

when running the eager/lazy test i get the following results, using randomSeed(2) to make the test fair.

3336402
Eager: 6015
3336402
Lazy: 5938

... so on my machine the lazy test, using the boolean ops, is a bit faster.


But the thing i actually want to point out is:
AFAIK bitwise operators in java work only on integer. So the result of a bitwise operation is an integer, and the operands are too.
This is interesting when looking closer at this line:

if (a < b & c > b | e == f & g != h)  ++counter;

a < b ... boolean
(a < b) & (c > b) ... two boolean operands and bitwise operator.

in that case the two boolean operands have to return an integer for the bitwise
operation to work properly.

when viewing the .class file with a java decompiler (i used http://java.decompiler.free.fr ) the line looks as follows:

if (((a < b ? 1 : 0) & (c > b ? 1 : 0) | (e == f ? 1 : 0) & (g != h ? 1 : 0)) != 0) counter++;


while the line using just boolean ops looks like this:

if (((a < b) && (c > b)) || ((e == f) && (g != h))) counter++;

Interesting. So the bitwise operator used on booleans actually converts these booleans to integer in order to operate. I didn't know that.

Last note: this kind of "optimizations" are also heavily depending on the used version of Java. It can be a Sun JVM, an Oracle one, an IBM one, an Apple one or an OpenJDK one, to mention but a few. And within these variants, there are version numbers.
All this to say that perhaps an optimization works in a version, and might be void in another. Some old tricks (using final, for example) are probably obsolete since a long time. And so on.
I fear there is no true recipe for speed, except avoiding the usual traps (like using the + concatenation operator to create a long string in a loop).