Wade Brainerd wrote: > > The only catch is that the drawing output > lags the tablet strokes by quite a bit. My > guess is that the event processing cannot > keep up with the data rate. I seem to remember > that there was a driver configuration related > to that which might be used to throttle down > the fire hydrant. > > > The mouse events go at a higher priority than the expose events, so the > screen update waits until you stop moving if it gets behind. But, at > the end your entire stroke should appear. I would be concerned about > reducing the update rate, it might lead to less accurate drawing.
It is true that reducing the update rate would lower the pen position resolution of lines...but the Bamboo tablet has a linear resolution of 2400+ lines per inch which is about 12X the XO pixel resolution and 24X your 2X reduced drawing canvas. As a result, even with skipping pen deltas of 24 or less the pen output events will still be at the finest drawing precision. This is not even including the fact that the brush is more than a single pixel wide typically. If you add an entry under the first wacom Xinput entry in your xorg-dcon.conf file like: Option "Suppress" "60" you'll get much better drawing response with the existing infrastructure. I tried 10-72 and to keep up with faster sketching or larger brushes, the rate needs to be at 50 or greater. After the above edit and a 3-finger-salute to restart the X server on the XO, Colors! basically worked well with the tablet. There is a command line configuration program (xsetwacom) that could be used to configure Wacom tablet settings without editing the xorg-dcon.conf file. I don't know if a restart of X would then be required. It might be possible to base a control panel interface calling the underlying utility per Tomeu Vizoso's previous mention in this thread. To improve beyond the Suppress technique will require improved event handling optimization in colors.py. My guess is that the best approach will be to encapsulate tablet specific handling at a lower level for efficiency. > I've got some optimizations planned to the C module which should make it > better, and I think there are some bottenecks in the X server that slow > things down and could be fixed, but my recommendation for now is to draw > slower :) Cool! > BTW, Colors! version 11 did not appear to have > the photo snap capability. Was that removed? > > > See Nirav's response. I'm also planning to add Paste support so you can > just snap the photo in Record (or whatever) and paste it into the > Reference image, then paint over that. I tried the earlier photo snap and it was awkward to toggle the underlying photo image. It would be more helpful if the photo could be drawn over as if on tracing paper. The toggle on/off would still be useful at different levels of refinement of the painting. There appeared to be a problem with the Zoom in and out function as zooming all the way out, and then back in results in the canvas offset by various amounts. I was not able to make it shift back without restarting the Activity. Finally, I'm not sure how to handle this but it was difficult to trigger the Frame exposure via the tablet since the drawing area seems to be exactly the entire screen. If it were to be extended a bit at the top then the Frame would be easier to get to from the tablet only. I've got an old serial Intuos that I'll try to get configured this weekend. I'll let you know how it goes... If we get this working, maybe Amazon could add a "People who bought this item [the XO], also bought this [Wacom Bamboo]"... :-) Best regards, Chris _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
