Created attachment 462477 [details] w3.org website in Midori 9.0 Both with Midori and Badwolf rendering show strange rendering (see attached image). It looks like only one colour is used, but other webpages seem to use two colours. Since the problem occurs with two browsers using WebKitGTK, I made a (not very educated) guess to report the bug here. This is on an iMac G5 (PowerPC 970FX) with OpenBSD current (macppc port).
Same problem with bug#219916 comment#4. WebKitGTK has USE_OPENGL_OR_ES build switch to disable OpenGL for minor operating systems which have a problem for OpenGL. WebKitGTK has WEBKIT_DISABLE_COMPOSITING_MODE env var to disable accelerated compositing. https://trac.webkit.org/wiki/EnvironmentVariables
Looking at your screenshot. At least, it seems that red and blue are swapped. This is the color conversion matrix. https://github.com/WebKit/WebKit/blob/9c06eb3162b5f48ee882984e91f8ac9d4f9f1fdd/Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp#L435-L445 I think there are more problems. You might need some more swizzling in BitmapTextureGL::updateContents. https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/texmap/BitmapTextureGL.cpp#L91
Cairo uses ARGB32 as the color format for its surfaces. On little endian systems, this is stored as BGRA. When we upload the cairo surfaces into textures, we upload them as BGRA indicating that when painting them we will change that format to RGBA. The TextureMapperGL::ShouldConvertTextureBGRAToRGBA flag used in BitmapTextureGL::updateContents() takes care of that (by selecting the appropriate color conversion matrix that Fujii linked). On big endian systems, cairo contents are stored as ARGB. This means that when uploading the surface contents to textures, we should use the flag TextureMapperGL::ShouldConvertTextureARGBToRGBA, which doesn't seem to be used. Something like this in BitmapTextureGL::updateContents() should fix the color conversion on big endian. #if G_BYTE_ORDER == G_LITTLE_ENDIAN m_colorConvertFlags = TextureMapperGL::ShouldConvertTextureBGRAToRGBA; #else m_colorConvertFlags = TextureMapperGL::ShouldConvertTextureARGBToRGBA; #endif
I tested the patch suggested by Miguel Gomez and it corrects the colours when WEBKIT_DISABLE_COMPOSITING_MODE=1 is used. So I opened a PR with this change: https://github.com/WebKit/WebKit/pull/25424 When accelerated compositing is used, at least on my system, black on white text is now displayed light gray on white instead of blue on white as before. Blue is yellow. I suspect that RGBA is confused as BARG.
Committed 275780@main (c37138cb8d45): <https://commits.webkit.org/275780@main> Reviewed commits have been landed. Closing PR #25424 and removing active labels.
I think that this bug should be reopened, because the colours are only fixed in non-accelerated mode.
.