View Single Post
Old 05-16-2012, 09:47 PM   #5
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by JoppyFurr View Post
Hi,

I have updated my program. It's now a bit smoother and has some new features.

Changes:
- Added MIT license
- Added a note thanking Geekmaster for code tips
- Multithreaded
- - - First thread to listen to the touch screen and write to the frame buffer
- - - Second thread to handle updating the eInk.
- Releasing in the top left of the screen now clears the image back to a blank grid
- Kindle framework stopped while running

Thanks for helping out Geekmaster :3
A huge performance improvement! Good job JoppyFurr!

In the code, the killall -STOP is really not the same as "framework stop" (or equivalent). It is really a pause (the complement of resume). I would rename the STOP_FRAMEWORK define to PAUSE_FRAMEWORK just to avoid confusion.

EDIT: That background grid does an excellent job of distracting your eye away from the ghosting artifacts left behind when erasing to black. Good idea there. Another method is to ERASE the ghosting with "color palette animation" like I did in the "goodbye" function in my newtrix demo (and used again in the gmvid.gmv.gz video file played with gmplay). Your method certainly saves on battery life though.

EDIT 2: You can demonstrate the multitouch driver bug with your program too (just like mine). Put two fingers on the screen and rotate them around each other. When they cross a common axis (same X or same Y coordinate, the points returned jump to the OTHER corners of the bounding box). You can still measure the diagonal for pinch and stretch like I do, but rotation gets a bit more difficult if you compensate for the multitouch bug in your code (which could break if they ever fix the bug). It is important to "future-proof" workarounds so that they can survive the bug they compensate for going away in the future.

EDIT 3: I see on two fingers that you sometimes sync at the wrong time, which OCCASIONALLY puts a point in the other bounding box corner. You should not sync on Y, because some frames only contain a singe X or single Y. And sometimes you START out of sync (wrong bounding box corner) without triggering the driver bug. There is a separate sync event you should use (see my script you linked to). Of course, that only matters when you use two fingers. I "oversimplified" it for my sigcap script to rely on ONLY one finger, just to make the code smaller and simpler.

Last edited by geekmaster; 05-16-2012 at 10:09 PM.
geekmaster is offline   Reply With Quote