tested to see if there are any regressions in the lang. there was some languages newly available but no dropped languages as long as I tested all of fonts packages which is available in Fedora. that looks good. though that might even affects on the result of the best font for certain language. so may still need another testing. just for updates On Wed, Sep 13, 2017 at 5:54 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: > Ok, now that you made a release, I'll go ahead and merge this so we get > maximum testing. I'm also making some more variable-fonts changes and I > prefer to merge this first and work on top. > > I'll continue regarding the lock in a separate thread. > > Thanks > > On Wed, Aug 16, 2017 at 9:10 PM, Akira TAGOH <akira@xxxxxxxxx> wrote: >> >> Speeding up the scanning is really nice but IMHO we can't remove the >> lock as long as fontconfig has a possibility to update caches from >> multiple processes at the same time. improving the speed of updating >> caches may reduces the chance to see the issue, but that's it. in >> other words, there are still an opportunity to see it if the condition >> is met. in fact, that issue was there since quite a long time ago. but >> it bagan to happen these days because of processing the updates of >> caches in parallel by the package manager etc. so I don't want to do >> that unless we have any idea to detect that breakage before writing or >> any way to do update cache safely. otherwise we'll see some wired >> issues in the future. >> >> On Tue, Aug 8, 2017 at 2:30 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: >> > Hi everyone, >> > >> > I have a proposed patchset speeding up fontconfig scanning by 10x, >> > simply by >> > not loading glyphs at all, and trusting fonts having correct cmap: >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=64766#c56 >> > >> > If no one has comments, I like to merge this and get it out for testing >> > in >> > the wild. >> > >> > After this, I think we should fix the relocatable feature to not touch >> > mmaped cache files. Here's my proposed approach: >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=101889#c17 >> > >> > After that, we should clean up the cache race patches and remove the >> > locking. We should accept that cache updates will always remain racy, >> > simply because we don't have or want to use the kinds of synchronization >> > primitives that guarantee no race. With scanning 10x faster this >> > shouldn't >> > be a problem in practice. I like to get back to each process trying to >> > update the cache and possibly discarding its result if another process >> > already did... >> > >> > Cheers, >> > >> > -- >> > behdad >> > http://behdad.org/ >> > >> > _______________________________________________ >> > Fontconfig mailing list >> > Fontconfig@xxxxxxxxxxxxxxxxxxxxx >> > https://lists.freedesktop.org/mailman/listinfo/fontconfig >> > >> >> >> >> -- >> Akira TAGOH > > > > > -- > behdad > http://behdad.org/ -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
