Skia needs to swizzle on big endian hosts
Categories
(Core :: Graphics, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox65 | --- | affected |
People
(Reporter: awilfox, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(5 files, 6 obsolete files)
|
652.74 KB,
image/png
|
Details | |
|
2.99 KB,
patch
|
Details | Diff | Splinter Review | |
|
2.33 KB,
patch
|
Details | Diff | Splinter Review | |
|
1.54 KB,
patch
|
Details | Diff | Splinter Review | |
|
34.69 KB,
patch
|
Details | Diff | Splinter Review |
| Reporter | ||
Comment 1•7 years ago
|
||
| Reporter | ||
Comment 2•7 years ago
|
||
| Reporter | ||
Comment 3•7 years ago
|
||
| Reporter | ||
Comment 4•7 years ago
|
||
| Reporter | ||
Comment 5•7 years ago
|
||
| Reporter | ||
Comment 6•7 years ago
|
||
Comment 7•6 years ago
|
||
Just to follow up on the great work already done here:
Using the patches already posted here, I was able to find out where the blue overlay is coming from.
I followed the approach of "Skia only knows LE, so we have to modify its input".
With this patch almost all elements have the right color now, without setting layers.force-active to true.
Text is still white on white in menus and sometimes in the address bar.
Comment 8•6 years ago
|
||
The white text color comes from antialiasing, which seems to be broken on big endian.
But not for all text, only those coming from XULTextBox.
I couldn't yet find a difference between other text and XULText and why AA breaks for one and not the other.
I attached a very ugly, hacky workaround to deactivate AA only for XULText (which is mostly visible in the sandwhich-menu and plugins).
Now the text is pixely but readable.
Comment 9•6 years ago
|
||
Updated version of the XULText-AA-fix.
"Fixed" it inside skia -> Antialiasing now works
Comment 10•6 years ago
|
||
One more problem:
Tab-titles that are too long to fit into a tab get faded out.
On big endian this is broken and instead of fading out, the tab gets white and the font transparent, leading to an unreadable tab-title.
This patch is not a real solution, but a hack (once again).
The real solution would have been to byte-swap the correct buffer, but I could not find it.
So the next best thing is to deactivate the fading-effect. Now all tab-titles are readable, albeit not as pretty to look at as they could be.
Comment 11•6 years ago
|
||
Thanks for your continued work on this issue!
Updated•6 years ago
|
Comment 12•5 years ago
|
||
I think I see the same issues on Solaris SPARC:
https://bugzilla.mozilla.org/show_bug.cgi?id=1491297
I'm confused. This bug is closed?
Comment 13•5 years ago
|
||
(In reply to msirringhaus from comment #9)
Created attachment 9111146 [details] [diff] [review]
mozilla-bmo1504834-part3.patchUpdated version of the XULText-AA-fix.
"Fixed" it inside skia -> Antialiasing now works
I have tried to upstream the patch and it seems it would nice if you can help here:
https://bugs.chromium.org/p/skia/issues/detail?id=9781
Comment 14•5 years ago
|
||
(In reply to Petr Sumbera from comment #13)
(In reply to msirringhaus from comment #9)
Created attachment 9111146 [details] [diff] [review]
mozilla-bmo1504834-part3.patchUpdated version of the XULText-AA-fix.
"Fixed" it inside skia -> Antialiasing now worksI have tried to upstream the patch and it seems it would nice if you can help here:
https://bugs.chromium.org/p/skia/issues/detail?id=9781
As discussed privately: You are more than welcome to use this (or any other of my) patches and try to get it into skia.
Thanks for the effort!
Comment 15•3 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•3 years ago
|
| Reporter | ||
Comment 16•1 year ago
|
||
I've come back to this now (has it really been six years??) and I've tried a new approach. What if we actually try to remove the endianness from the entire graphics stack, and then - if we're on BE - swizzle all data coming through Skia?
And honestly, this is somewhat working with both 128 and Nightly (133a1). I'm even somehow able to sign in to Discord with it - something that would have thrown at least three or four assertion failures before this patch. I had a full six workers crash on my first attempt, even.
However, I'm not sure if this is the right way forward or not. Notably, the tab title fade out works properly now (i.e. the workaround from Bug 1504834#c10 is no longer needed). The native widgets and icons don't, though - and trying to open the hamburger menu throws an assertion failure. So I guess what I want to ask is: since this shouldn't actually change behaviour on LE, but it does improve BE, is this something I should continue to pursue? Could this end up landing, and is this an approach with longevity? Or is this the wrong way forward?
TODO: test on LE to make sure it doesn't change anything, test on Fennec to make sure it doesn't break Android which is very Special, and figure out what is going on with these silly menus:
(t=3.21142) |[1][GFX1-]: Replay failure: DrawTarget Creation READ (t=42.3973) [GFX1-]: Replay failure: DrawTarget Creation READ
[34540] Assertion failure: false, at /home/awilcox/Code/contrib/mozilla-unified/gfx/webrender_bindings/Moz2DImageRenderer.cpp:433
| Reporter | ||
Comment 17•2 months ago
|
||
I've taken a look at the patches referenced in the repo linked in Bug 1990103, and they are both primitive and don't reflect the latest work on this bug - either the "old" way, or the way I began working on with Comment 16.
Does anyone have input on the work I did there? I have tested it on LE and found it has absolutely no change in behaviour. The only change in behaviour from the patch is that BE works, and somewhat better than the other approaches. But again, I don't know if this is even a desired change. If it isn't, then I'll go back to trying to get the swizzles to work better. (Notably, I'm quite perturbed by the tab title fade - not that it's a huge deal, but it's a paper cut that feels like it should be completely unnecessary.)
Description
•