Catsxp Forum

UPDATE :

It may help to fix these problems, here the comments of Mr @win32ss the developer of Supermium browser and his advices to fix these problems ! :

"This looks like GDI font rendering. The text offset is a known issue with the Skia renderer when using GDI."

"I replied in the issue in the Chromium-for-windows-7 repository that this was effectively Chromium's normal handling of GDI. This indicates a possible failure to initialize DirectWrite if GDI was not specifically enabled (and would not be possible in a fairly vanilla Chromium)..... "

Here the comments of Mr . @win32ss the developer of Supermium browser about these problems :


"This looks like GDI font rendering. The text offset is a known issue with the Skia renderer when using GDI."

""I replied in the issue in the Chromium-for-windows-7 repository that this was effectively Chromium's normal handling of GDI. This indicates a possible failure to initialize DirectWrite if GDI was not specifically enabled (and would not be possible in a fairly vanilla Chromium)."

Not related to GDI offset

StartupParm.txt
[#--disable-direct-write] -> [--disable-direct-write]

Test disable DW

Thanks so much for your help Mr @Catsxp ! i will try your advise and also try the beta version !

here approximately the comment of Mr E3kskoy7wqk the develper of Chromium-for-windows-7 about this problem :

"On my end, dwrite.dll loaded normally, and everything in DWriteFontProxyImpl::InitializeDirectWrite() worked correctly.

The return statements in:

if (factory_ == nullptr) {
// We won't be able to load fonts, but we should still return messages so
// renderers don't hang if they for some reason send us a font message.
return;
}
and

if (!collection_) {
return;
}
were not executed.

However, I have no visibility into what's happening on your end. In any case, I've applied the skia.patch and uploaded this build, hoping it will work properly on your end."

Disabling DW did not help in my case...

I would recommend to stay with the kernel 135 and wait for a more usable version than 136. Maybe they will fix the GPU issues in the future.

Update :

The developer of Chromium-for-windows-7 makes for me new version to fix these problems, but sadly the same problems remain : illegible unreadable content of web pages, illegible settings menu, accent color that hides the writing......



here a part of discussion between Chromium-for-windows-7 developer and Supermium developer and me to try to fix these problems , maybe it can help :

"- @win32ss Thank you for the reminder, I believe this is a deeper underlying reason.

I think the direct cause of this issue is that I forgot to replace the version of d3dcompiler_47.dll with version 10.0.22621.2428. The d3dcompiler_47.dll in Windows 11 SDK version 26100 can cause issues on Windows 7 and even some versions of Windows 10 (see: https://github.com/chromium/chromium/bl ... up-windows).

Another solution to the problem is to install KB4019990. This update installs d3dcompiler_47.dll from Windows 8.1.

...... I have uploaded the version with the replaced d3dcompiler_47.dll; you can try it to see if the display works properly. If the problem still isn't resolved, I will try to investigate the issue with skia GDI font rendering......

Okay, the method I mentioned earlier might not necessarily work. I might really need to look into what's going on with Skia GDI font rendering.Okay, the method I mentioned earlier might not necessarily work. I might really need to look into what's going on with Skia GDI font rendering.

It can be confirmed that the issue started appearing from https://github.com/e3kskoy7wqk/Chromium ... 6.0.7083.1, and it was not present in https://github.com/e3kskoy7wqk/Chromium ... 6.0.7071.1 . Additionally, the problem only occurs in the 32-bit version (see https://github.com/e3kskoy7wqk/Chromium ... /issues/38 ).....

Since I have been unable to reproduce this issue on my end (even when I force-enable Skia GDI rendering), and I am not familiar with Skia, I have decided to try a binary search approach to solve the problem. It would be even better if someone could assist me.

-Unfortunately, GDI is no longer sufficient for meeting Chromium standards (for example, Outlook does not work with GDI), so I would concentrate on restoring DirectWrite support.

(but if you do want an imperfect fix for the GDI offsets, here it is: skia.zip)

Is DWrite.dll loaded into the main Chromium process? And if not, can you try and see if the DWriteFontProxyImpl::InitializeDirectWrite() method is being reached, and if it is, what is happening in the method?

-On my end, dwrite.dll loaded normally, and everything in DWriteFontProxyImpl::InitializeDirectWrite() worked correctly.

The return statements in:

if (factory_ == nullptr) {
// We won't be able to load fonts, but we should still return messages so
// renderers don't hang if they for some reason send us a font message.
return;
}
and

if (!collection_) {
return;
}
were not executed.

However, I have no visibility into what's happening on @trimechee's end. In any case, I've applied the skia.patch and uploaded this build, hoping it will work properly on @trimechee's end.

-Update :

Bad news, Mr. @e3kskoy7wqk, I tried the latest version of Chromium-for-Windows-7 with the skia.patch, but sadly, the same problems remain : illegible content of web pages, illegible settings menu, accent color that hides the writing...

Now I will try the new version of Catsxp and possibly add this parameter --disable-direct-write to the StartupParm of Catsxp as recommended by Mr @Catsxp : the Catsxp browser developer, and see if that fixes these problems...

I also noticed this new flag in Supermium 132 :

chrome://flags/#disable-browser-font-smoothing-win

Disable Browser Font Smoothing on Windows
The internal font smoothing (antialiasing and subpixel rendering) is disabled with this switch enabled. – Windows

This flag doesn't exist in Chromium-for-Windows-7 kernel 136 , but MY theory is that maybe this flag is enabled by default and integrated into the Chromium-for-Windows-7 code, hence these display issues..."

Update :

Mr @Catsxp , thanks for the new version, but there is bad news : i install the last version of Catsxp Version Ver: 5.5.3 (32 bits), i even disable harware acceleration, i even added in catsxp://settings/StartupParm : --disable-direct-write


but the same dipslay problems remain : illegible unreadable content of web pages, illegible settings menu, accent color that hides the writing......

Update :

i don't know if these tweaks can fix these problems but
Mr. @JAKill02, in the Supermium repository, gives me these important advices :


"Problems with the display of text and links on Windows 7 arise due to the following parameters / flags :

#disable-browser-font-smoothing-win ( Switch it to a value [Disabled] )

#force-gdi ( if enabled, switch it to a value [Disabled] )

--disable-direct-write ( If you have this flag inscribed somewhere [shortcut, or launching .bat file, etc.], delete it )

Video playing problems are eliminated by activation of this flag :
#disable-accelerated-video-decode (switch it to [Disabled])

You see, in all modern Chrome browsers, hardware acceleration of the video by default is disabled, so it just needs to be turned on.
Apparently, Google developers believe that everyone has powerful processors now, and there is no need to turn on hardware acceleration from the video card, but if you have not a very powerful processor, this will entail problems when playing a video."

Mr @ Redfox, thanks so much for your advise ! yess i think the best idea is to return back to version 135 with the hope that future versions will fix these problems !

In my opinion, this should have no substantial relationship with DW
It should be a graphics driver issue