Update gfx/2d/Types.h #1925

Open
opened 8 months ago by jobbautista9 · 5 comments

Mozilla's version has new features such as CICP as well as new members for enum classes SurfaceType, SurfaceFormat (particularly OS_RGBA which libjxl needs), FilterType, etc. We'd probably want these to make backporting future libraries that depends on those features easier.

Blocks #1769.

Mozilla's version has new features such as CICP as well as new members for `enum` classes `SurfaceType`, `SurfaceFormat` (particularly `OS_RGBA` which libjxl needs), `FilterType`, etc. We'd probably want these to make backporting future libraries that depends on those features easier. Blocks #1769.

Looks like this is going to be a bit troublesome to backport. Mozilla's Types.h removed NS_SIDE_TOP/RIGHT/BOTTOM/LEFT in bug 1317588, and xref says we have 28 files using NS_SIDE_TOP alone.

Looks like this is going to be a bit troublesome to backport. Mozilla's `Types.h` removed `NS_SIDE_TOP`/`RIGHT`/`BOTTOM`/`LEFT` in [bug 1317588](https://bugzilla.mozilla.org/show_bug.cgi?id=1317588), and xref says we have 28 files using `NS_SIDE_TOP` alone.

I think for #1769 I will just add OS_RGBA to SurfaceFormat for now in the PR I will make for that issue just to satisfy nsJXLDecoder. So this issue no longer blocks #1769 in my view.

I think for #1769 I will just add `OS_RGBA` to `SurfaceFormat` for now in the PR I will make for that issue just to satisfy `nsJXLDecoder`. So this issue no longer blocks #1769 in my view.

I've decided to abandon the OS_RGBA backporting effort and instead went for using OS_RGBA's value which is R8G8B8A8. Turns out that there is much more going on in Mozilla's version of CreateSurfacePipe than I've expected, like the aInFormat and aOutFormat thing which I really don't want to delve into right now. Looking at the code it looks like all JPEG-XL images are expected to have an alpha channel anyway, so I think my workaround should be safe.

I've decided to [abandon](/jobbautista9/UXP/commit/494c79b17ea1b1a6f4dfa9ddc7fe6edcfedc29f0) the `OS_RGBA` backporting effort and instead went for using `OS_RGBA`'s value which is `R8G8B8A8`. Turns out that there is much more going on in Mozilla's version of `CreateSurfacePipe` than I've expected, like the `aInFormat` and `aOutFormat` thing which I really don't want to delve into right now. Looking at the code it looks like all JPEG-XL images are expected to have an alpha channel anyway, so I think my workaround should be safe.
Owner

Looks like this is going to be a bit troublesome to backport. Mozilla's Types.h removed NS_SIDE_TOP/RIGHT/BOTTOM/LEFT in bug 1317588, and xref says we have 28 files using NS_SIDE_TOP alone.

Mozilla has been refactoring a lot of macros into enums. Those changes aren't necessarily difficult but may be a lot of work anyway depending on how frequent the macros are used. The choices made by mozilla for naming don't even necessarily make the end result easier to read either, so some serious scrutiny required for porting.

> Looks like this is going to be a bit troublesome to backport. Mozilla's `Types.h` removed `NS_SIDE_TOP`/`RIGHT`/`BOTTOM`/`LEFT` in [bug 1317588](https://bugzilla.mozilla.org/show_bug.cgi?id=1317588), and xref says we have 28 files using `NS_SIDE_TOP` alone. Mozilla has been refactoring a lot of macros into enums. Those changes aren't necessarily difficult but may be a lot of work anyway depending on how frequent the macros are used. The choices made by mozilla for naming don't even necessarily make the end result easier to read either, so some serious scrutiny required for porting.

Yeah, it's not difficult to me either, it's just going to be tedious. Maybe I would do it one day.

Yeah, it's not difficult to me either, it's just going to be tedious. Maybe I would do it one day.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MoonchildProductions/UXP#1925
Loading…
There is no content yet.