search

pharo-project / pharo

Pharo is a dynamic reflective pure object-oriented language supporting live programming inspired by Smalltalk.
http://pharo.org
Other
1.2k stars 355 forks source link

Corrupted fonts #2336

Closed macta closed 3 years ago

macta commented 5 years ago

In a fresh P7 image on OSX - I loaded GT via metacello and ran through some of the examples, clicking on things and flipping to another application (notes) to record my observations. Over time, the menus in Pharo get corrupted and show glyphs or spaces and subscripted text (see photos). I have repeated this twice and got the same results. However interestingly, when I saved the corrupted image to a new file (to report it), it then cleared the fonts back to normal.

This is how I loaded GT (from their website)

EpMonitor current disable. [ Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load ] ensure: [ EpMonitor current enable ].

GtWorld asClass openTour.

These are the types of corruptions I saw after 5ish minutes:

image

image

image

image

guillep commented 5 years ago

Hi Tim, I've been using Pharo7 for a couple of months already, and I haven't seen that particular issue. There are certainly issues with font rendering but I don't think its the same issue.

Could you confirm that this happen in a normal pharo usage? Otherwise I'd suggest that you open an issue in gt's issue tracker, as gt is maintained by feenk.

PharoProject commented 5 years ago

On 25 Jan 2019, at 21:01, Guille Polito notifications@github.com wrote:

Hi Tim, I've been using Pharo7 for a couple of months already, and I haven't seen that particular issue. There are certainly issues with font rendering but I don't think its the same issue.

Do you change your font ? Make it bigger for example ? Use the Dark look ?

Try it and them try scrolling by any means through a long method.

macta commented 5 years ago

I’ll try again with that image and try changing the font without saving to see if it fixes it too. But weird that an image save would correct it?

I will also log it with Feenk - but surely a library shouldn’t be able to impact base Pharo functionality like this (still they do funky stuff I guess).

I’ll play some more - as font stuff has come up a few times.

macta commented 5 years ago

Saving the image to a new name - clears this error? I think Esteban confirmed that a save does clear some font cache. When I had saved the image I wasn't able to corrupt the fonts again - so it looks like there is something in a fresh image when you load GT that causes this.

guillep commented 5 years ago

Hi all, we have found the cause of this problem finally with Pablo, this is due to race conditions in concurrent code calling FreeType. This bug was apparently always there but Calypso's lazy tabs (that are created in background processes) made this bug come to the surface.

Some solutions and more details are discussed here: http://forum.world.st/FreeType-and-the-over-amorous-glyphs-overlapping-td5098109.html

I'm working on a solution initially for Pharo7.

Pharo Smalltalk Developers - FreeType and the over amorous glyphs (overlapping)
FreeType and the over amorous glyphs (overlapping). Hello, After checking the problem with Guille, we have the hypothesis of the source of the problem. We have seen that accessing Free Type is not...
guillep commented 5 years ago

Hi all,

To me it's super difficult to reproduce the issue in Pharo7.0.3. I was able to build a case to reproduce it but it's not reproducing it reliably enough < 3% of the times executed...

Here is a changeset that can be installed in Pharo7 or Pharo8 FreeTypePatch.cs

The patch introduces a serialization of other accesses to FT_loadFont that were not protected.

If someone tries it for some time It would be really cool.

macta commented 5 years ago

I was holding off to see how easily it occurs in my new 703 image, and when i flipped open my laptop it was there again - so it seems to appear readily once its kicked in. I'll try this change and see if it now slows or stops it.

macta commented 5 years ago

Since adding this file-in I've had my image lock up twice now - once after saving, and another just browsing code. Cmd-. does nothing, the pharo osx menu is accessible and if I zoom and contract a few times eventually i can cause a redraw that just paints half the windows (previously there was a taskbar and other windows).

Not sure if this is this fix, or whether its mirage - but this shouldn't be possible. It just raises the question of pharo stability. Fortunately my little pet project isn't enterprise, but if i was a company, I would be upset.

image

estebanlm commented 5 years ago

hi @macta, Is this still an issue? I have the impression that is fixed upstream.

astares commented 5 years ago

Unfortunately I've seen it on Windows again on a new image this week ...

akgrant43 commented 5 years ago

I'm still regularly seeing corrupted fonts with:

Pharo7.0.3
Build information: Pharo-7.0.3+build.158.sha.0903ade8a6c96633f07e0a7f1baa9a5d48cfdf55 (64 Bit)

on Ubuntu 16.04.

astares commented 5 years ago

If one reinitializes FreeType in SettingsDialog it is gone ... so I think it it somehow related to one of these sources:

I tried to reinit some of the class vars, pools used to find the cause. So far without luck.

Ducasse commented 5 years ago

I got problems from time to time in P8 too

Ducasse commented 5 years ago

astares do you have a reproducible case?

macta commented 5 years ago

I still get it too, a bit less and possibly a bit less severe - but that might be because I started not loading the tab switching package (which when I reported this was the one that drove it over the edge - and I could demo it to @guille at Pharo days. I think it was this example that hilited the race condition).

Note - to fix it, I find that saving the image cures it, you press save and watch the fonts correct in front of your eyes

astares commented 5 years ago

I usually get it from time to time on new images. Yes - saving seems to cure it.

That's why I said it seems to become cured by running some initializers who either correct things or adopt to platform.

guillep commented 4 years ago

Pharo 9.0 177a16763fb410ad36cc119cb499b004a3622536

There is already some time that I don't see this issue. I think @tesonep integrated something else related to this after the last comment in this issue (16-june-2019).

Can somebody confirm?

astares commented 4 years ago

Yes - havent seen it for a long time in recent images. Hopefully it is gone...

gcorriga commented 3 years ago

Can this issue be closed?

Ducasse commented 3 years ago

Yes too old.

astares commented 3 years ago

Yes - did not appear again yet.

macta commented 3 years ago

Close it and I’ll spend some time on the newest image and reopen if it still happens - I suspect it might as it was never fully fixed but the new van work may have helped.

On 4 Jan 2021, at 20:16, StéphaneDucasse notifications@github.com wrote:

 Yes too old.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.