[cp-patches] FYI: CairoGraphics2D speedup

Sven de Marothy sven at physto.se
Wed Jun 14 18:51:02 UTC 2006

On Wed, 14 Jun 2006, Mark Wielaard wrote:

> Nice, but unfortunately that doesn't work for ComponentGraphics which
> manipulate the X state. In that case we need locking before drawing. We
> used to get that for free since ComponentGraphics overrides draw(Shape)
> and fill(Shape). So we need to override these three new public methods
> so we do correct locking again.

> Unfortunately I am unable to say how much speed loss this gives because
> without this patch the benchmark program kept crashing on me. With this
> it runs reliable though.

Zero speed loss compared to before. You're not doing any less work.
> We might want to think a bit more about how we do this locking since the
> current way means we do three separate JNI calls and a little extra
> bookkeeping in ComponentGraphics to account for the gdk lock not being
> reentrant. It is probably much more efficient if we had some
> needs_drawing_lock flag inside CairoGraphics itself that subclasses
> could set if needed.

Absolutely not. Never. No way. I refactored the drawing classes precisely
to get away from bullshit like this. CairoGraphics draws to a generic 
Cairo context. Most Cairo context do not require any kind of locking. 
That's the whole idea of why things are done the way they are. 

Trust me, the existing code is a lot more thought through than your idea.
What you're proposing here is going to first introduce a gdk dependency in 
CairoGraphics, which I do not want at all. 

Second, it will slow down all the other drawing contexts by performing an 
unncessary check for whether to do locking.

Third, you're not going to gain much speed regardless, because the 
overhead of making two extra JNI calls is negligable compared to the time 
required to release and get the locks, and in comparison to the fact that 
all those drawing operations have to go through Xlib (and possible 
client-server communication), which is why they need locks to begin with.

This short-sighted thinking is what made the Graphics2D code such a mess
in the first place. It's cleaned up now, and let's not go back there.


More information about the Classpath-patches mailing list