Win2D 1.14.0 – text analysis, typography, TableTransfer3DEffect, color management, and ComputeHistogram

Win2D version 1.14.0 is now available on NuGet (for Windows 10 or Windows / Phone 8.1) and GitHub.

New features:

Improvements to existing features:



Comments (7)

  1. juanpablogc says:

    I have just seen that even the Win2D Gallery app was updated, really interesting effect how the bars are moved with the histogram. And really detailed the typography options it is really complete.

    Apart learning and digging, really great feature having this: TrackAsyncAction, thanks it helps a lot for big images.

    I am digging more about the CanvasDevice class, corresponds to…/hh404478(v=vs.85).aspx. If I understand well what it really means is a device context more than a 'Device' isn't it?

    And is in someplace of Win2D a class that implements ICanvasResourceCreatorWithDpi? what is its purpose?

    I really enjoy the Win2D team results and way of work, thanks @juanpaexpedite

  2. Juan,

    CanvasDevice corresponds to an ID2D1Device interface.  This represents an active GPU rendering device, plus whatever set of resources have been created against that device.  A D2D device context (ID2D1DeviceContext interface) corresponds to the Win2D CanvasDrawingSession class.

    The ICanvasResourceCreatorWithDpi interface is implemented by several types including CanvasControl and CanvasRenderTarget.  This article talks more about the design:…/DPI.htm

  3. Chris says:

    What are the criteria for experimental features becoming stable and will there be any announcement when they become stable or get nixed?

  4. > What are the criteria for experimental features becoming stable and will there be any announcement when they become stable or get nixed?

    We are actually right now in the middle of discussing what that criteria should be.  So far it' has been simple: everything implemented prior to when we released v1 is stable, and everything implemented since then is experimental.  We have not yet moved anything from experimental to stable, so to date this criteria has been "never".

    Clearly this needs to change 🙂  and we are thinking it should change soon.

    Absolutely, there will be clear announcement on the blog whenever an API is declared stable, or when we make deliberate breaking changes to experimental features.

  5. Chris says:

    Ah, guess I had good timing then. 🙂

    Yeah, I'm a bit worried by the number of experimental features that I want to use and it would be bad to start relying on them just to have them suddenly poof.  If an experimental feature is solid yet is determined to be feature creep, would it make sense for those kinds of things to be pushed into a separate Win2D Extras/Extensions library?

    Or do you think it's extremely unlikely that an implemented feature will ever be completely removed?

  6. This is where the difference between theory and practice gets important 🙂

    In theory, the "experimental" tag means we reserve the right to do anything to an API.  Change it, delete it, turn it into a dancing frog…

    In practice, to date I don't think we have ever outright deleted an API.  We've renamed some things, and moved a few things to different places, but the vast majority of our APIs have stayed unchanged since their first release even though marked as experimental.

    So a lot comes down to where your tolerance for risk is at.  If you absolutely can't deal with having to make code updates to match changes in newer Win2D versions, don't use anything marked experimental.  If you worry about the small chance we might randomly decide to delete something entirely (even though we've never done that yet), ditto.  If you're ok with occasional updates to your code being needed and want access to the latest & greatest functionality, then go for it…

    It might help to explain the rationale for why we might change an API.  Since Win2D ships every 2 weeks, we release a lot of things that have only recently been implemented.  After we ship something, it is possible that:

    1) We might look at the design again a few weeks later and thing dang, we did that the wrong way, now I see a much better approach that we should have used instead…

    2) We might move on to implement a related area of functionality, and notice some pattern between the two areas that could be better expressed if we change the way we did the earlier part

    3) We might get feedback from customers using the API that tells us better ways to do it

    The experimental tag serves two purposes: to warn you that an API is new and so there has not yet been time for these possibilities to play out, and also to indicate that if we do think of a better way to do it, we will not hesitate to change the API accordingly.

    When we remove the experimental tag, that will indicate that enough bake time has passed that we don't expect any more sudden insights in that area, and also that if we somehow do have such an insight, we would instead prioritize maintaining compatibility over acting on it.

    Could we decide to delete an API entirely?  I guess, maybe, if we decided it was dumb and that there was no purpose to it.  But if you had a use for such an API, you could always then protest the deletion, and most likely we would then put it back upon learning that there was indeed a use for it.  And in practice, such a case has not come up yet…

  7. Chris says:

    Thanks for the thorough response!  I do understand that Win2D is still getting fleshed out, so once the current experimental features have become stable I assume there won't be another significant build-up of them any time soon.  Makes me wonder what else might get added over the next year that isn't in the backlog, though.

Skip to main content