stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Revitalizing StumpWM


From: David Bjergaard
Subject: Re: [STUMP] Revitalizing StumpWM
Date: Tue, 28 Jan 2014 14:07:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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?

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. 

Cheers,

    Dave





reply via email to

[Prev in Thread] Current Thread [Next in Thread]