I’ve got my Wacom tablet reading class working fine, and have been trying to do a simple drawing test app.
It works, but i’m having a little trouble with the drawing.
In order to get a smooth line drawn, i’ve chosen to use a Path to stroke the line between the current cursor position and the previous one (the thickness determined by the pressure).
The tablet’s axis range is roughly 10000x7000, about ten times greater than screen resolution. To determine where to draw, it converts the tablet axis values to a floating point screen resolution.
The problem is, when the pen is moving slowly, nothing gets drawn. I imagine that it’s because the lines are too short (i.e. < 1.0f) for the graphics renderer to want to bother with. I don’t actually know this of course!
I would appreciate any comments you may have jules, as i wish to fix this but would like to know what the problem is first - and you’d know best!
well i’ve changed the code a little, and it seems to prove that the graphics doesn’t bother rendering if it’s too short. I’ve got it accumulating the total dX and dY at each draw operation, and if it’s less than 1.0f, it won’t draw the path right away, instead building up the path until either dX or dY are larger than 1.
Is there any way to change this? I guess it’s not possible really… i can’t expect the Graphics to draw a line that’s less than a pixel long! :hihi:
i think i’ll just draw an ellipse if the distance moved is small, and do the path thing if it’s moving more quickly. that makes a bit more sense i think.
well, paths can be drawn that are less than a pixel long, they’ll just come out as a semi-transparent pixel.
I guess you must be drawing a line onto an image each time the cursor moves? If so, you’d get better results by storing up all the cursor positions until the button is released, then re-rendering them all as one large path after they let go of the button. That’d mean creating a preview layer over the background to show what they’re drawing, which is what most painting apps seem to do.
yeah, i thought it would be best to render the whole path at the end. but i’m not sure how i’d go about getting the preview system working- after all, it would need to show these shorter bits!
i’ll look into doing it this way. i guess i’d need to use the PathStrokeType::createStrokedPath() tho for each section, in order to have variable thickness along the length of the path.
well it works okay from line-to-line, but only if each step is processed separately. i just implemented a preview/render scheme, but the only way to have the variable thickness is to add each segment as a stroked path to the final render path… and that gives me the exact same problem i had before! :’( i guess the juce drawing classes just aren’t quite as suited to the task as i’d hoped.
actually, it’s not quite so bad- if i set the ‘extraAccuracy’ value of the createStrokedPath, it’s happy to fill in the gaps that were otherwise there, although it does take it a little while (because when there are gaps, it’s due to there being lots of little paths that are too short to appear properly)
