display_lists: minor compile-time op size tweaks

[gaaclarke]

This has no effect on runtime behavior. It just makes the following compile-time changes:

1. Makes the size of the op type 1 byte to match the size in DlOp (This really should have been a compilation error).
2. ~~Converts all the size comments to static_asserts, updates them or deletes them when they were incorrect.~~

Pre-launch Checklist

• [x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
• [x] I read the Tree Hygiene wiki page, which explains my responsibilities.
• [x] I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• [x] I listed at least one issue that this PR fixes in the description above.
• [x] I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• [x] I updated/added relevant documentation (doc comments with ///).
• [x] I signed the CLA.
• [x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gaaclarke]

Actually, this PR might fail CI since the sizes may vary depending on the platform and std implementation. Let's see.

[flutter-dashboard[bot]]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[flar]

Actually, this PR might fail CI since the sizes may vary depending on the platform and std implementation. Let's see.

Windows does not play well with the size estimates. Also, many of the fields vary in size for 32-bit and 64-bit pointers.

[flar]

• Makes the size of the op type 1 byte to match the size in DlOp (This really should have been a compilation error).

I'm not sure why this is an issue or why it should have been a compilation error...?

[gaaclarke]

Windows does not play well with the size estimates. Also, many of the fields vary in size for 32-bit and 64-bit pointers.

Yea, i reverted it. I'm not sure what we want to do. Some of the comments were way off. We could just static assert for one platform to have a baseline and a ballpark estimate. I just reverted for now.

[flar]

Another direction to take would be protective asserts or FML_CHECKS that assert that we can fit all of the enum values into the type bitfield. Something along the lines of FML_CHECK(op->type == T::Type) in the Push method to verify that the value we read back from the field is the value we tried to put there. Or, static assert that the max enum value fits in the number of bits we assign to the field?

[chinmaygarde]

Are we making progress on this? The tests are failing.

[chinmaygarde]

Added the WIP tag. But please close if no progress is being made.

[gaaclarke]

Added the WIP tag. But please close if no progress is being made.

I don't think it's worth spending any more time on considering the weird behavior from the windows compiler.