Sciss wrote:
>here's the paint code for the jog dial which gets placed on the top
>left corner (yes, it belongs to "hardware sample rate").
>...
>g2.translate( 0.5f + in.left, 0.5f + in.top ); // tricky disco to
>blur the outlines 'bit more
That translate() concerns me, mainly because 'in' is an instance field
(Insets type) that isn't strictly coupled to getInsets(). It's sorta
coupled, but that's one of my concerns.
Another concern is that I thought the Insets were already accounted for in
the Graphics's transform passed to paintComponent(), so translating AGAIN
by in.left and in.top seems redundant. I may be mis-remembering, though,
and could easily be wrong.
Seen in the larger picture, so to speak, those concerns seem misplaced,
however, because if that translate() was really the problem, then the knob
and its belly would be displaced, which they aren't.
The 0.5f offset I understand: you're setting it "between pixels", so it
renders edges that are certain to anti-alias across multiple discrete
pixels on-screen. Nice trick.
Next, looking at the screen-shots of the display:
<http://lists.apple.com/archives/java-dev/2006/May/msg00507.html>
it looks to me like a graduated "dial" with tick-marks around the circle is
what's being drawn at the weird place far from where the "knob" is
rendered. I may be misperceiving the tick-marks, though. It's hard to
tell, even if I hold a magnifier up to the screen. There's a distinct
top-center pixel on the displaced arc-thing, which might be a rendering
artifact, though it doesn't look like it to me. There also look to be
tick-marks at about 60-degree angles down both sides of top-dead-center,
but those are much more plausible as rendering artifacts.
Anyway, my question is this: is the Jog class just the knob. or is it the
knob and the dial with tick-marks? I'm asking because I don't see code in
Jog.java to draw tick-marks. I'm also asking because it's hard to tell
just by reading the code which drawing method invocations are supposed to
render which elements of the knob. The "belly" I understand: it's the
"belly-button" indentation, which is the small spot offset from the center
of the knob. It's the rest of the ovals and arcs, and how they relate to
the knob and shadows, that aren't entirely clear to me.
So, if there really are tick-marks, and the dial is a separate component
from the knob, then an obvious guess is that one thing isn't being drawn
directly atop the other. But it doesn't make sense to me why you'd create
two components to render a knob separate from its dial and tick-marks,
because that seems too complicated to be worth doing.
On the other hand, if there aren't any tick-marks, then I don't know what
that arc-shaped thing in the displaced upper-left is supposed to be. If
it's not a dial or graduation marks, maybe it's a shadow, but if it is,
then it looks like there's already a shadow or shading on the knob
(rendered in its correct place), so I'm still not sure what the arc thing
is supposed to be.
Other than that, I see nothing wrong with Jog.java's painting code. It may
be worthwhile to look farther up the component hierarchy. Maybe it's some
OTHER component that's wrong, and it's screwing up the Graphics context for
the Jog component, or Job's subtree.
Lastly, I would see what happens if you remove the code that restores the
stroke and transform at the end of paintComponent(). This is more in the
line of trying to get it to break in a different way, rather than any
specific idea of a solution. Sometimes seeing something break differently
reveals clues about the other breakage.
Good luck, and if you do track down the problem, please post the outcome to
the list, even if it's that you couldn't fix it and filed a bug-report.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
