-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update System.Drawing to reflect GDI+ changes #32873
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
@@ -157,6 +157,23 @@ public static IEnumerable<object[]> GetEncoderParameterList_ReturnsExpected_Test | |||
new Guid(unchecked((int)0xa219bbc9), unchecked((short)0x0a9d), unchecked((short)0x4005), new byte[] { 0xa3, 0xee, 0x3a, 0x42, 0x1b, 0x8b, 0xb0, 0x6c }) /* Encoder.SaveAsCmyk.Guid */ | |||
} | |||
}; | |||
|
|||
#if !NETFRAMEWORK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: for tests and test data, we usually use, if (!PlatformDetection.IsFullFramework)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm,
ImageTests.cs(161,36): error CS0117: (NETCORE_ENGINEERING_TELEMETRY=Build) 'PlatformDetection' does not contain a definition for 'IsFullFramework'
What am I missing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IsFullFramework
, obviously :)
It was removed in dotnet/corefx#37972.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh 😄 .
I'm a bit confused, because dotnet/corefx#37972 and #28619 seem to indicate tests would no longer run on full framework, yet they do for System.Drawing.Common.
@safern What's the way forward here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test should run on netfx
only if the library targets netstandard2.0
. In that case they should test the functionality of the netstandard2.0
library running on NetFX, not testing NetFX code itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's somewhat weird to have new APIs that are not present on certain platform. What will happen if you call them? I'd except something like PlatformNotSupportedException but that only works for new types and only if partial facade is generated. In this case it's new members on existing type.
You will not be able to reference them anymore as for ref we only build live for netcoreapp3.0 and netcoreapp5.0. The netfx assets harvested. So now that you mention it we no longer build netfx assets for System.Drawing.Common anymore as we just get them from the latest package and re-ship them in the new package. Maybe it is fine removing the netfx tests for this library.
cc: @ericstj @ViktorHofer @danmosemsft @JeremyKuhne -- I'm leaning towards removing testing netfx for S.Drawing.Common. What do you guys think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you guys think?
My only concern is that surfacing unintentional deviation in behavior from Framework becomes more difficult without runs there. If we had better test coverage I'd worry less, but I think we're pretty far from adequately covering GDI+ behavior in our current tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's a fair point. I would suggest leaving the tests on this PR and using the NetFramework
property in PlatformDetection
; then we can discuss further if we want to stop running tests for netfx in this project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, unfortunately we went the full circle on this one - just using PlatformDetection
does not work, because there's a reference to Encoder.ImageItems
which was added as part of this PR, but is not present in NetFx.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. Ok, well this at least was a good discussion. Then we will need to go back to the compile time condition, sorry about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than a comment looks good to me.
cc: @JeremyKuhne
@qmfrederik, if you can address @safern's feedback, seems like we can then get this merged. Thanks. |
@@ -16,6 +16,9 @@ public sealed class Encoder | |||
public static readonly Encoder LuminanceTable = new Encoder(new Guid(unchecked((int)0xedb33bce), unchecked((short)0x0266), unchecked((short)0x4a77), new byte[] { 0xb9, 0x04, 0x27, 0x21, 0x60, 0x99, 0xe7, 0x17 })); | |||
public static readonly Encoder ChrominanceTable = new Encoder(new Guid(unchecked((int)0xf2e455dc), unchecked((short)0x09b3), unchecked((short)0x4316), new byte[] { 0x82, 0x60, 0x67, 0x6a, 0xda, 0x32, 0x48, 0x1c })); | |||
public static readonly Encoder SaveFlag = new Encoder(new Guid(unchecked((int)0x292266fc), unchecked((short)0xac40), unchecked((short)0x47bf), new byte[] { 0x8c, 0xfc, 0xa8, 0x5b, 0x89, 0xa6, 0x55, 0xde })); | |||
public static readonly Encoder ColorSpace = new Encoder(new Guid(unchecked((int)0xae7a62a0), unchecked((short)0xee2c), unchecked((short)0x49d8), new byte[] { 0x9d, 0x07, 0x1b, 0xa8, 0xa9, 0x27, 0x59, 0x6e })); | |||
public static readonly Encoder ImageItems = new Encoder(new Guid(unchecked((int)0x63875e13), unchecked((short)0x1f1d), unchecked((short)0x45ab), new byte[] { 0x91, 0x95, 0xa2, 0x9b, 0x60, 0x66, 0xa6, 0x50 })); | |||
public static readonly Encoder SaveAsCmyk = new Encoder(new Guid(unchecked((int)0xa219bbc9), unchecked((short)0x0a9d), unchecked((short)0x4005), new byte[] { 0xa3, 0xee, 0x3a, 0x42, 0x1b, 0x8b, 0xb0, 0x6c })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@safern, @carlossanlop, I assume we want to add XML comments to these in order to populate the docs? For consistency maybe we should do so for all the fields here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub, good catch. @qmfrederik could you please also include XML docs for these new APIs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@qmfrederik the only information that the existing APIs need on top of them as triple slash is their summary, which you can get from their MS Docs documentation.
OK, I think I addressed the feedback. The XML comments keep the same format used in the previous versions of the framework. It doesn't look like GDI+ has docs with an elaborate description of these encoder parameters, so I left it at that. |
@carlossanlop could you sign off on the XML comments? |
src/libraries/System.Drawing.Common/src/System/Drawing/Imaging/Encoder.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Drawing.Common/src/System/Drawing/Imaging/Encoder.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Drawing.Common/src/System/Drawing/Imaging/Encoder.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for documentation, @qmfrederik. But just for consistency with the existing documentation in MS Docs, please consider applying the suggestions I offered.
public static readonly Encoder ImageItems = new Encoder(new Guid(unchecked((int)0x63875e13), unchecked((short)0x1f1d), unchecked((short)0x45ab), new byte[] { 0x91, 0x95, 0xa2, 0x9b, 0x60, 0x66, 0xa6, 0x50 })); | ||
|
||
/// <summary> | ||
/// An <see cref="Encoder" /> object that is initialized with the globally unique identifier for the save as CMYK category. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we try to use the full name even if it is not needed, but not sure. @carlossanlop ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean using <see cref="T:System.Drawing.Imaging.Encoder" />
? No, it's not needed in triple slash comments. If the API was not recognized within this context, VS would give you an error. But in this case, we recognize the Encoder
type.
When the project gets built and the triple slash comments get converted to their respective xml files, all API names will be automatically converted to their full name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the T:
prefix results in build errors: error CA1200: Avoid using cref tags with a prefix
Encoder.Quality.Guid, | ||
Encoder.LuminanceTable.Guid, | ||
Encoder.ChrominanceTable.Guid, | ||
Encoder.ImageItems.Guid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the ImageItems
property was added in this PR, but is not present in the NetFramework
builds since they type forward to System.Drawing, which does not have this property.
How should we tackle this?
- Add support ValueTypePointer encoder parameters - Support ColorSpace, ImageItems and SaveAsCmyk encoders
/azp help |
Supported commands
See additional documentation. |
/azp run "runtime (Installer Build and Test Linux_x64 Debug)" |
Commenter does not have sufficient privileges for PR 32873 in repo dotnet/runtime |
The build failures seem unrelated but I don't have sufficient permissions to trigger a rerun. |
I re-ran them. You can always go to the checks tab and click on re-run no? |
Nope, I don't have those permissions. #718 has some more information. Looking forward to a green CI and getting this merged! |
This is the last part of the work done in dotnet/corefx#40181 which was pending API approval (#30543).
ValueTypePointer
encoder parameters (doc)ColorSpace
,ImageItems
andSaveAsCmyk
encoders (doc)GetEncoderParameterList
was broken for the JPEG encoder, which now returns (an empty list of) parameters of typeEncoderParameterValueTypePointer
. This was broken in .NET Framework, too (see e.g. this StackOverflow report)Fixes #30543