Workaround for the CPU usage issue

[GoogleCodeExporter]

I added a simple workaround for the CPU usage. Until a notification
function is available in libcwiid, this is sufficient IMO.

Original issue reported on code.google.com by vanhtu1...@gmail.com on 24 Jan 2008 at 2:19

Attachments:

• whiteboard_20_4.patch

[GoogleCodeExporter]

More global vars eliminated.

Original comment by vanhtu1...@gmail.com on 24 Jan 2008 at 10:52

Attachments:

• whiteboard_20_5.patch

[GoogleCodeExporter]

main.c cleaned up, helpers functions (draw...) were moved to a separate file.

Original comment by vanhtu1...@gmail.com on 25 Jan 2008 at 12:14

Attachments:

• whiteboard_20_6.patch

[GoogleCodeExporter]

Hello vahtu!

I have tried your patches. Nice work. Your idea of calling update_cursor in the
callback function is very clever. CPU usage is fine now. I have implemented it 
in my
internal development version and it works like a charm.

I have some questions about your code:

- The indentation. Your style is confusing to me. You seem to alternate between

if (cond) {
}

and

if (cond)
{
}

(I prefer the latter)

- C does not allow variable declarations if not at the beginning of a block
- The "const" things. Are they necessary?
- The "h" coefficients. Don't you think is better having them cached rather than
calling matrixGetElement() every time? Little's Law...
- The thing with matrix objects: I think that in my implementation they were 
clearer
(all the functions deal with pointers, all functions return pointers, not 
structures)

There are several things I like about your code. Maybe we can discuss these 
issues here.

Thanks for your work!

Original comment by pere.ne...@gmail.com on 25 Jan 2008 at 7:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks, I was beginning to worry about it. Btw, just call me Tu :) .

 - I actually don't care much about the coding style. Although I do try to keep it
consistently, I prefer ease of understanding over consistency when I see fit. 
For
example:
   + x = x+3 * (5-y)/2; versus x = x + 3;
   + malloc(1337); versus strlen( sizeof(char)*foo_amount );

 - Oh yes, but reordering them when facing strict compilers is a very easy task. And
for the record, "//" comment style is not standard C either :) . It also helps
readability and improving performance of the code.

 - Was it in C++, 'h' (now called 'transform'ation matrix), it could have been kept
as a member variable and passed around. In C though, it would introduce another
static, or global variables, which I really, really (really!) try to avoid when
possible. Besides, it is an obvious optimization when necessary, not at the 
moment
though. Only games and performance-intensive apps need rigorous optimizations. 
If you
need raw speed, try assembly instead of C/C++.

 - As I said, I was being silly during the imagination of a Matrix class ready to
consume. Since the source has been largely refactored, you can see that the 
matrix
class is actually used very little in the code (only a few separated 
functions). I'd
prefer writing it in C++ and patch them if someone, somewhere, somehow needs 
the code
in C.

I've thought of a way to allow multiple control schemes, I will post it in a 
moment.
Gotta go eat something :) .

Cheers.

Original comment by vanhtu1...@gmail.com on 25 Jan 2008 at 10:50

[GoogleCodeExporter]

I meant "Ahmdal's law" (not little's law).

Original comment by pere.ne...@gmail.com on 25 Jan 2008 at 11:24

[GoogleCodeExporter]

Original comment by vanhtu1...@gmail.com on 31 Jan 2008 at 9:46

• Changed state: Fixed
• Added labels: Type-Patch
• Removed labels: Type-Defect