Martin Vermeer wrote:
>> >> > I guess that this one is for you to test. Rather than draw a new
>> >> > line on each cursor blink, I bitBlt cached pixmaps. It works (we
>> >> > still have a blinking cursor, either 'normal' or 'foreign'), but I
>> >> > have no idea whether it works as desired (zero traffic).
>> >> 
>> >> Here's an improved version that responds to changes in the cursor
>> >> color also.
>> >> 
>> >> --
>> >> Angus
>> > 
>> > No, I'm afraid not. The traffic is now 450 bytes/s rather than 500 (as
>> > shown by Firestarter).
> 
>> So we did some good, just not enough? Are you able to give me any
>> pointers to the remaining sources?
> 
> I doubled the blink rate (400 -> 200 msec) and traffic went from 450 to
> 900 B/s (estimated; firestarter's resolution is 0.1 kB/s). So I think it
> is really the cursor and nothing else. This is for a quiescent LyX
> containing one new, empty doc.

Interesting. If you look at the source, you'll see that I recreate the 
pixmaps only if the pixmap dimensions change. The rest is just copying the 
contents of an existing pixmap to an area of another existing pixmap.

If you add some print statements you can check that the pixmaps are 
created only occassionaly (the {no,v,h}cursor_pixmap_.resize(...) calls).

If that hypothesis is correct, then the traffic is instructions to copy 
one existing pixmap to an area of another existing pixmap and there's 
nothing we can do about it.

That's my understanding at least.

-- 
Angus

Reply via email to