search

microsoft / Win2D

Win2D is an easy-to-use Windows Runtime API for immediate mode 2D graphics rendering with GPU acceleration. It is available to C#, C++ and VB developers writing apps for the Windows Universal Platform (UWP). It utilizes the power of Direct2D, and integrates seamlessly with XAML and CoreWindow.
http://microsoft.github.io/Win2D
Other
1.82k stars 287 forks source link

InkExample: Can't Erase #369

Closed bricelam closed 8 years ago

bricelam commented 8 years ago

The Ink example includes code to handle erasing, but the InkPresenter.StrokesErased event is never raised in custom drying mode.

What is the proper way to support erasing strokes in custom drying mode?

shawnhar commented 8 years ago

That's up to you. When you do custom drying, you take ownership of the dried ink and can store/draw/update/delete/etc however you like.

In the Example Gallery implementation, we have a "Delete Selected" button.

bricelam commented 8 years ago

So to imitate the default InkCanvas behavior you'd have to keep track of the eraser path, calculate which strokes it intersects and remove them. That seems excessive.

I wonder why they decided not to fire the event. I suppose making custom drying mode mean, "You keep track of the strokes, not us," makes their code simpler.

Oh well. Works for me. Should the dead code be removed from the sample?

shawnhar commented 8 years ago

This behavior isn't about implementation simplicity - it's kinda the definition of what custom ink drying is!

When you enable custom drying, you are taking responsibility for the dried ink. It is up to you to store it, organize it, display it, or edit it as needed. At this point the InkCanvas no longer knows anything about the dried ink strokes. It handed them across to you during the dry operation, then promptly forgot all about them.

The advantage is that when you own the ink strokes, you can do interesting things with them. Maybe your app supports pan or zoom, so you may display (and hit-test) your strokes in a different location from where they were originally drawn. Perhaps your UI wants to collapse sections of a document that may include strokes, or organize them into tabs, or layer other UI elements over the top of the ink. You might be using ink to annotate a complex document, then later want to re-flow this document to fit a new layout, and as you do so move each stroke to keep it next to the same part of the document it was originally drawn over.

None of these things would be possible if InkCanvas continued to own the full list of ink strokes and edit this on your behalf. If you want a simple behavior where InkCanvas does own all the strokes and provides basic editing capabilities for them, don't turn on custom drying.

bricelam commented 8 years ago

It's the definition of what custom ink drying is!

Thanks, after thinking about it, I came to the same conclusion. If ink "drys" by dripping down a wall, calculating erased strokes based on the original stroke position wouldn't be very useful.

That said, there's still dead code in the example. PR #370 addresses this.