>Michael Raskin <38a93...@rambler.ru> writes: > >>>> 3. Text drawing is slower with this fork, especially when some character >>>> is drawn after it is purged from cache as too old. As far as >>>> I understand this doesn't affect fixed fonts, but it is something to >>>> document… >>>Can you explain point 3? I'm happy to merge this with the core, I just >>>want to understand exactly what you mean. I'm actually using this >>>version on one of my computers now. >> >> I have a custom command (listing all tags of all windows) that produces >> a lot of text. If I run it twice, second run is almost always >> instantaneous. But sometimes the first run of that command takes a few >> seconds. Under adverse conditions it can even take ten seconds to draw >> the message. >If I'm following, users of bitmap fonts won't see a difference, but if >you choose to render truetype (TT) fonts then you may see a delay if stump >tries to dump a lot of text on screen?
I didn't test it well, but apparently fixed font works fine. >The takeaway is: >1. If this is reintegrated, users will get the same old > performance "out of the box" >2. If you choose to use TT fonts, you may see performance impacts when > dumping large chunks of text to the screen > >Michael, are you aware of why this is the case? Is it an issue that can >be fixed in StumpWM, or is it in the TT rendering library? It would be >helpful to have an example command that just dumped a grid of characters >so that we could ensure that there isn't something funky going on >elsewhere. I feel it is a problem with clx-truetype, but I am not completely sure. _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
