Overhead of X?

Egbert Eich eich at suse.de
Thu Apr 20 09:29:12 PDT 2006


Bilderbeek, Manuel writes:
 > Hi,
 > 
 > > X does a little more than just a memset() of the enitre framebuffer.
 > > Filling the entire framebuffer with just one solid color is 
 > > nothing that
 > > the solid fill code in fb (that's what you are using unaccelerated) is
 > > really optimized for. Therefore it will perform some tests 
 > > and operations
 > > that are not required for this particular operation.
 > 
 > Would all those tests take so much CPU that it makes it 3 times slower?
 > So, 2/3 of the time is used for calculations and checks?
 > After all, the fill code is just supposed to fill a solid rectangle, so
 > the filling itself should be comparable. Or not?


memset() is highly optimized to fill one single large range of 
memory with a single byte value.
Some implementation use hand crafted machine code for this, 
select the right code sequence for the size and alignment of
the memory. 
XDrawRectangle() cannot use a lot of these optimizations or it's
useless to add them for your corner case.
Maybe you want to profile your problem a little better. This
will tell you where the CPU cycles go - instead of letting us
guess.

 > > Furthermore memset() is ususally higly optimized for your 
 > > architecture.
 > 
 > If the fb fill routine would use memset, would that matter? (I don't
 > know if it does that, but I don't see why it couldn't...)

It's not feasable as it will only be applicable to a few corner cases
- like yours.
Not very many people are interested in a solid color full screen
rectangle.

 >  
 > > This seems to be a poor comparison.
 > 
 > How can I make it better?

Maybe you should look for a more useful less corner case test scenario?

 > 
 > Maybe running the application in the root window might help? (Could save
 > some checks!)
 > How would I do that, anyway? (Run a Java app in the root window...)

Well, even if you paint right into the root window your operations will
still observe clipping by children.

Cheers,
	Egbert.



More information about the xorg mailing list