[Trac #259] sketch activity is laggy drawing on the tablet.

[Zarro Boogs per Child]

#259: sketch activity is laggy drawing on the tablet.
---------------------+------------------------------------------------------
 Reporter:  jg       |        Owner:  blizzard
     Type:  defect   |       Status:  new     
 Priority:  blocker  |    Milestone:  BTest-1 
Component:  sugar    |   Resolution:          
 Keywords:  relnote  |  
---------------------+------------------------------------------------------
Changes (by jg):

  * priority:  normal => blocker
  * summary:  Drawing activity is laggy drawing on the tablet. => sketch
              activity is laggy drawing on the tablet.

Old description:

> I was playing with the early paint/drawing program under Sugar on the
> touchpad.
>
> It is very "laggy" on the OLPC, and the curves drawn on the screen poor
> (straight line segments).
>
> This is generally caused by not keeping up with a very rapid series of
> events, so has probably not be noticed on conventional desktops which are
> much faster. And event compression is likely eliding the intermediate
> positions.
>
> Note that X has the concept of "motion history" buffers, which allow an
> application to move from being strictly event driven (where it is easy to
> fall behind and have poor interactivity) to a polling mode where you can
> use motion events as "hints" that motion has occurred, and then query the
> window system to get the exact history of motion, which you can handle in
> a batch (which is almost always a much, much faster operation), and gives
> you all the intermediate positions, which may easily otherwise been
> compressed out of existance.
>
> See XGetMotionEvents and XGetDeviceMotionEvents.

New description:

 I was playing with the early sketch program under Sugar on the touchpad.

 It is very "laggy" on the OLPC, and the curves drawn on the screen poor
 (straight line segments).

 This is generally caused by not keeping up with a very rapid series of
 events, so has probably not be noticed on conventional desktops which are
 much faster. And event compression is likely eliding the intermediate
 positions.

 Note that X has the concept of "motion history" buffers, which allow an
 application to move from being strictly event driven (where it is easy to
 fall behind and have poor interactivity) to a polling mode where you can
 use motion events as "hints" that motion has occurred, and then query the
 window system to get the exact history of motion, which you can handle in
 a batch (which is almost always a much, much faster operation), and gives
 you all the intermediate positions, which may easily otherwise been
 compressed out of existance.

 See XGetMotionEvents and XGetDeviceMotionEvents.

 Also, there needs to be some UI for moving the tablet area around, and, I
 suspect, drawing with something other than a tiny pen.

 I don't think this one is ready to see the light of day.

 Unless I hear objects, we'll pull this from BTest-1, though may leave it
 long enough to go on the couple hand built units as demonstration of the
 dual mode tablet. (e.g. don't pull this one until after the image for the
 hand built units has been cut).

-- 
Ticket URL: <http://dev.laptop.org/ticket/259#comment:2>
One Laptop Per Child <http://laptop.org/>