Horizontal and Vertical Paths not drawn

[corsc]

If I attempt to draw Horizontal or Vertical paths then this line

if ( !canvas.quickReject( drawingPath, Canvas.EdgeType.BW ) ) {

causes them to not be to drawn.

Changing from Canvas.EdgeType.BW to Canvas.EdgeType.AA has no effect, the only resolution I can come up with is to remove the check and that seems extreme/risky.

[moagrius]

Hmm... can you post the invocation of the drawPath method? I can't recreate this issue - the sample app shows some basic path drawing here - does that work for you?

[corsc]

Sorry, I cant find the code that I had for this, I added support for custom path drawings (i.e. animated paths) and have since refactored the lib for that.

If memory serves it was similar to your sample app only simpler. I was using:

public DrawablePath drawPath(final List<double[]> positions) 

to draw exactly horizontal and vertical lines, e.g. 50,50 to 150,50 or 50,50 to 50,150

[corsc]

The refactoring to support different path drawing implementations uses a similar proxy pattern to our work on TileSetSelectors. It could use some cleaning up and maybe a rebase after the other PR but would you be interested in that code too?

[moagrius]

yeah definitely... it'd be nice to offer an implementation that used drawLines as well (which is much more efficient than draw path, but has a lot less options and is IMO fairly unattractive visually).

generally speaking, i'm very open to any improvements that don't break existing API.

[Eteokles]

Are you planning a new version of tileview integrating some improvment or new features authorizing api breaking ? Maybe you can create a development branch specially dedicated for it ... ?

[moagrius]

hey @skaor - fwiw, the new features @corsc is talking about would not be API breaking, and are therefore good candidates for a merge (just as his last PR was merged). more broadly, at some point i'll probably introduce a version 2, which may or may not break v1's API - I'd do my best to deprecate-and-replace, but if it's necessary for a new major version, that'd be acceptable. probably not for a while, though - TileView is actually from another widget MapView that ended up needing enough of a rewrite that TileView was justified. Other than long-click (which could actually be a subclass), so far there's not a lot that's been suggested that can't be managed with new API... Is there something specifically you're referring to?

[Eteokles]

Not for this time, but i will find :D I seen the @corsc features is not api breaking and i see his excellent work ;) It's more out of curiosity, to encourage the development and evolution of this beautiful API.

[moagrius]

@skaor cool, thanks. i don't think it's a bad idea to start a development branch, but it'll probably be a little while - there's still several commits i haven't made, and want to make sure things are relatively "settled" before then.

thanks for your feedback and input