Re: [STUMP] Revitalizing StumpWM

[Michael Raskin]

>Michael Raskin <address@hidden> 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.