Rick Brewster

This compute shader's performance advantage seems to be that it greatly reduces the number of texture sampling instructions. It does not reduce the computational requirements -- each output pixel still needs to do the same amount of work. But there's up to an 87.5% reduction in texture sampling instructions because a sample that is used to compute multiple output pixels is only retrieved once. It likely doesn't reduce VRAM bandwidth because the GPU would be using an internal cache (e.g. L2) anyway, but it will reduce the bandwidth pressure on that internal cache.

PrecisionEffect is a pass-through effect that uses a pixel shader to read the input image. This ensures Direct2D can't optimize it away. So yes, it is essentially forcing an intermediate buffer so that the next effect in the chain will consume the source at the given precision. Source -> Precision -> NextEffect This contrasts with PassthroughEffect which is a proper "passthrough" effect -- it uses ID2D1TransformGraph::SetPassthroughGraph() so it essentially "washes away" at render time as if it didn't even exist in the first place. It's not really useful for an effect graph, but it does have uses in some niche cases for architectural purposes. DynamicImage (e.g. PdnDentsEffect) uses this so that it can hand you the PassthroughEffect which you can plug into an effect graph, but then it can change which image/effect is plugged into that PassthroughEffect. This means you don't have to keep retrieving the DynamicImage's "output" when you change its properties (DynamicImage is not actually an ID2D1Image/ID2D1Effect). It's very beneficial to use PrecisionEffect instead of a CompatibleDeviceContext.Bitmap because 1) that let's Direct2D manage the rendering process and memory management, and 2) it permits Paint.NET to manage rendering with tiles along with progress reporting and cancellation support. Otherwise you're forcing everything to render during OnCreateOutput(), during which there is no progress reporting or cancellation support.

You'll have to try this out and let us know how well it works for your specific scenario.

My understanding, and the way I use the term, is that transparent is completely see-through (alpha = 0), while translucent is partially see-through ( 0 < alpha < 255 ). And then of course opaque is, well, neither transparent nor translucent (alpha = 255).

This sort of crash, which is a RecreateDeviceContextException on a software rendering path, usually only happens when there's low- or out-of-memory. But I don't see evidence of that in the crash log, the amount of physical memory and free pagefile looks fine 🤔

Nope. Use layers. The user experience does not need to be changed. Everything is behaving as intended and as it should.

BTW this really does seem to be the clincher. BMP (on disk) and DIB (in memory, or at least on the clipboard) just aren't treated the same, even though they should be.

When copying images with transparency from Krita or GIMP, they are BITMAPV5HEADER, do specify BI_BITFIELDS, but do not include the 3 masks. And WIC can't decode them! (after inserting a BITMAPFILEHEADER at the start) mspaint sorta side-steps this by copying only a CF_DIB and a PNG. It does not copy a CF_DIBV5 to the clipboard. I'm using the latest version with transparency and layers support. So, again, apps should prefer PNG if it's on the clipboard. Include DIB/DIBV5 for the sake of legacy apps, but don't waste your time trying to make sure it's compatible with all other apps because that just isn't possible.

So from what I can tell for BMP storage, you include the 3 bitmasks when doing BITMAPV5HEADER + BI_BITFIELDS. This is with straight alpha. When copying to the clipboard as a CF_DIBV5, you do not include the 3 bitmasks when doing BITMAPV5HEADER + BI_BITFIELDS. This is also with straight alpha. Chrome does it differently. For an image with transparency (e.g. the forum logo, https://content.invisioncic.com/r125076/monthly_2020_09/getpaint_whitetext.png.9b52024e6a4fb3fcc770ebb1beb86df7.png), it will copy to the clipboard specifying BI_RGB, and 32-bits, and then it will use premultiplied pixels. This also seems to be Firefox's strategy. This seems to be the de facto spec. For whatever reason that's what other imaging apps are doing. Ergo, PDN's current implementation is, for lack of a better word ... correct.

It would appear that BMP and DIB, despite being the same thing, are not actually handled uniformly.

I'm getting similar results. If I use WIC to save a BMP, and then skip past the BITMAPFILEHEADER and place the remaining bytes on the clipboard, and paste back into various apps: Paint.NET: Works fine, obviously. WIC can handle its own output. mspaint: Refuses to paste the image GIMP: No transparency, and shifted right by 3 pixels Krita: Includes transparency, still shifted right by 3 pixels This is for a BITMAPV5HEADER bitmap w/ BI_BITFIELDS.

That should include any 32-bit BMP saved by PDN for the last 5+ years.

FWIW, WIC adds the 3 masks when writing out a V5 bitmap/DIB. That's canonical enough for me.

Why v4? I was under the impression that only v1 (BITMAPINFOHEADER) and v5 (BITMAPV5HEADER) are relevant

Welp, here we go again 🤔 I'll move the issue to the v5.1 milestone, hopefully we can reach clarity by then

I'm not doing that

Rendering performance is only affected by visible layers. (Technically speaking, non-visible layers still require some processing but it's negligible.)

It doesn't look like it's actually be edited, there's just a bunch of commits for infra stuff: https://github.com/MicrosoftDocs/win32/commits/docs/desktop-src/gdi/bitmap-header-types.md The documentation for BITMAPV5HEADER still states, in several different ways (but of course never really directly saying it) that this is not the way it should be done. It does say that bV5ClrUsed can be non-zero for a 32-bpp DIB, but that those color values are to be used for some kind of palette optimization (obviously a legacy consideration at this point). It also has a nonsensical explanation for how color profiles should be encoded (3rd paragraph in Remarks) ... I actually implemented color profiles support in the v5.1 codebase for BMP files as part of the color management feature work, but it's disabled because that's a Pandora's box I'm not willing to open yet. And yet, as you point out, the Bitmap Header Types page does explicitly say that there should be 3 color mask values in addition to the embedded color mask values (bV5RedMask et. al.). I'm still not convinced that the 2nd copy of the masks is supposed to be there, other than the "normalization of deviancy" Wikipedia link you provided -- in other words, the spec is de facto the implementation, which was accidentally crowdsourced out to every application or library that handles DIBV5s. And everyone got it wrong in a multitude of different ways and we just have to deal with it now. So we must find a way to unambiguously encode and decode in a way that achieves maximum compatibility. At least for decoding you can look at the total size of the payload (header + bitmap + anything else) -- if there's an extra 12 bytes then assume that the 3 masks are there, otherwise they're not. Easy enough. On the Paint.NET side I haven't been seeing any issues here, so my code for that seems to be working (knock on wood). Encoding is another matter because then you're contending with the decoding implementation of every other app. That's currently where the trouble is. And there isn't really a good unit test for this because it would require obtaining all of those other apps, something I am not interested in paying for or dealing with. At least for now we can probably focus on Chrome, Firefox, Office (Word, etc.), GIMP, Krita, mspaint, and any other popular free(ware) software. I'll reopen the issue over on GitHub and poke into this some more for the 5.0.13 servicing release. It sounds like what you're saying is that the fix is to add in the 3 masks. It may also make sense to just punt this over to WIC -- have it save a BMP to an in-memory stream, skip past the BITMAPFILEHEADER, and copy the remaining bytes to the clipboard.

A practical solution might be to write a little program that implements something called a clipboard hook. Basically it gets notified whenever the clipboard changes. When it sees a DIBV5 put onto the clipboard, it will either 1) Remove it if a PNG is also on the clipboard, or 2) Decode the DIBV5, re-encode as PNG, put the PNG on the clipboard, and remove the DIBV5. Obviously this would break pasting into apps that don't support PNG, but I'm sure things could be filtered with allow/block lists. Anyway this is just an idea.

Welcome to the world of DIBV5s and the Win32 clipboard

@AndersM as you can see this keeps popping up, e.g. https://forums.getpaint.net/topic/124628-1-px-line-on-top-of-every-image-pasted-from-paintnet/ from today

Read the posts above. Solution is to use a format other than PNG, e.g. PDN, TIFF, lossless AVIF.

Because DIB(non-V5) doesn't support transparency, and not all apps handle PNG. When I say "it's a legacy format" I mean that we shouldn't be shedding blood and tears over getting it right, we should just consider it to be a lost cause and accept it how it is, and encourage other apps to support and prefer PNG. You could also say that cash is legacy and problematic compared to debit/credit cards. Why keep using it then? Because it's still useful for a variety of reasons, and we're not yet to the point where we can just stop. And maybe we'll never reach that point, either for DIBV5 or cash, and that's something we have to accept. It's not a lost cause, we can still improve the state of the world with respect to either, but there will always be some app that someone wants to use that only supports DIB/DIBV5, just like there will always be someone out there who only has cash or some merchant who isn't willing/able to handle cards. (Also, there isn't yet a law banning cash in favor of cards, at least not in the U.S.) (I'm not sure cash vs. card is a proper good analogy, and I'm not trying to stake out a political position on the matter, but hopefully you got the point) Another way to improve this situation would be for Windows itself to step in and fix up / homogenize the clipboard data, possibly with compatibility shims for legacy apps which are known to do the wrong thing.

(btw I made some more edits to my most recently reply that may have been after your reply)

Basically it's like this, Paint.NET is placing a correctly formed DIBV5 on the clipboard. I'm going to assume this unless proven otherwise, such as via an in-depth technical discussion by experts here at https://forums.getpaint.net/topic/122848-pasting-dibv5-image/) Apps have varying degrees of buggy ways of copying and pasting DIBV5s DIBV5 is supposed to be a simple format, but it isn't due to how it's evolved over the last ~30 years and its poor documentation/specification This led to DIBV5 essentially being an ambiguously defined format due to both its buggy specification and inconsistent implementations across many, many apps PNG does not have any of these issues and is far superior in all ways except for encoding performance (i.o.w. how long it takes to copy it to the clipboard). This could probably be rectified if we got a PNG library with a "super fast compression" mode (which may already exist, although WIC certainly doesn't support that unfortunately). Therefore, if a PNG is on the clipboard alongside the DIBv5, just use the PNG. All this pain would be avoided if Firefox and Paint Tool SAI would just do that. DIBV5 should be considered a legacy clipboard format at this point, only included for the sake of apps that don't (yet) handle PNG. No matter what changes I make to the DIBV5 clipboard copy/paste code, it's guaranteed that a bunch of other apps will either 1) not copy its data to the clipboard correctly such that PDN will handle it, or 2) not read PDN's DIBV5 from the clipboard correctly. This is what happens Every. Single. Time. I. Have. Ever. Changed. The. Clipboard. Code. It is not possible to get 100% compatibility between all apps. At this point you need the equivalent of winning a case at the US Supreme Court to get me to change this code (which I considered that discussion linked in #1 to be an example of). It's not worth the trouble otherwise.